Speaking for the Rick Hudson Fan Club, thank you for your wonderful,
amazing work on the Go GC...
https://blog.golang.org/ismmkeynote
...and for this reminder that we don't want programming practice to
preclude continuing innovations.
On Wed, Dec 4, 2019 at 9:52 AM Rick Hudson wrote:
>
Breaking the Go CGO pointer rules comes up periodically and the rules
have not changed. Applications have lived with the rules simply
because breaking them results in revisiting the application code
every time a new Go release comes out. Did the compiler improve and
some object is now
On Wed, Dec 4, 2019 at 6:48 AM Robert Johnstone wrote:
>
> Thanks for the quick reply. I had not considered the write barriers, but if
> the Go objects are "live" longer than the held in C, it would work.
The write barriers do not look only at the pointer being stored, they
also look at the
Hello,
Thanks for the quick reply. I had not considered the write barriers, but
if the Go objects are "live" longer than the held in C, it would work.
I definitely agree that there are risks associated with this approach. We
are giving up some of the safety of Go. Unfortunately, we are
On Tue, Dec 3, 2019 at 7:20 PM Robert Johnstone wrote:
>
> The section on passing pointer to C in the cgo documentation is quite clear
> that letting C hold pointer to Go memory is not allowed. I'd like to better
> understand the limitation. Frankly, because of the architecture of a system
>
Hello,
The section on passing pointer to C in the cgo documentation is quite clear
that letting C hold pointer to Go memory is not allowed. I'd like to
better understand the limitation. Frankly, because of the architecture of
a system I'm working on, the inability to transport pointers is
