| Age | Commit message (Collapse) | Author |
|---|
|
Before this change, there were no users of slot int variable in the Go
world (just a pointer to it that ended up in C world only), so Go's
garbage collector would free it and its value could not retrieved later
(once a pointer to it comes back to Go world from C world).
Keep a pointer to it in the Go world so that does not happen.
Fixes #218.
|
|
If we store values by uintptrs the GC may try to inspect their
values when it kicks in. As the pointers are most likely invalid,
this will result in an invalid pointer dereference, causing the
program to panic. We can fix this by storing values by an int
index value instead, returning pointers to those indices as
handles instead.
|
|
|
|
Using 0 as the first slot indice leads to not being able to
differentiate between a handle to the first element or a
NULL-handle. As current code may check whether the pointer is
NULL, change the first indice to be 1 instead.
|
|
|
|
As the Go runtime can move stacks at any point and the C code runs
concurrently with the rest of the system, we cannot assume that the
payloads we give to the C code will stay valid for any particular
duration.
We must therefore give the C code handles which we can then look up in
our own list when the callbacks get called.
|
