Check for runtime of memory & need of runtime.KeepAlive()

[dertseha]

The garbage collector can be aggressive in removing (finalizing) objects. With several methods in the API taking the raw pointer, which furthermore sometimes need to be stable for longer time for asynchronous operation, double-check whether the wrapper needs to keep some of the things "alive" (see runtime.KeepAlive()), or it needs explicit documentation.

Further input: Read up on proper use of unsafe.Pointer().

[dertseha]

Searching and reading about unsafe.Pointer I am curious of two things:

• Will an object pointed to by unsafe.Pointer be garbage-collected? Apparently no: https://stackoverflow.com/a/70513591
• Will the memory of an object pointed to by unsafe.Pointer potentially be moved (and pointer updated): unclear.

For the second question, this snipped in the long documentation on unsafe.Pointer may be relevant:

The compiler handles a Pointer converted to a uintptr in the argument list of a call to a function implemented in assembly by arranging that the referenced allocated object, if any, is retained and not moved until the call completes, even though from the types alone it would appear that the object is no longer needed during the call.
(emphasis mine)

This implies that memory could be moved, and it is only prevented from doing so if the strict pattern is applied of uintptr(unsafe.Pointer(&x)) (potentially even requiring calls to assembly functions) -- a pattern which the wrapper currently doesn't use.

By this, I fear that the cases where this may trip up any runtime are far more compared to the effort to implement some sort of fixed allocation system (see also #23)

[dertseha]

Some concrete answers and descriptions when move happens here: https://go101.org/article/unsafe.html - section "Fact 3". This also references https://go101.org/article/memory-block.html#where-to-allocate , which provides an example when this can happen.

In short: Evidence accumulates that having unsafe.Pointer in the public API may lead to many problems, and a better API will be necessary. This is at least true for the asynchronous operations, which can either be explicit (e.g. non-blocking calls to some of the buffer operations), or implicit, through the use of waitList parameters for the Enqueue* calls .

And even more so, all the internal pointer magic needs to be double-checked.