4 ms·

go shared libraries interoperable with c. How does this work? As far as I understand Go is moving to a copying collector, so any pointers passed to C may becom

go shared libraries interoperable with c. How does this work? As far as I understand Go is moving to a copying collector, so any pointers passed to C may become wild pointers when garbage collection is performed. On go-nuts, Go's developers have been warning that passing arrays to C by getting the address of the first element of the slice will be unsafe for this reason.

Daemon404 11y ago
Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack address change now?
- danieldk 11y ago
  The Go spec does not contain the stack or heap, so I guess that in principle it's fair game for the collector to relocate it in memory. In some future version it's only safe to use memory in C-land that was allocated in C-land.
  - AnimalMuppet 11y ago
    Wouldn't it be safe to use in C-land as long as you kept a reference to it in Go-land? Something like: Create memory in Go-land Use memory in C-land Dispose of reference to memory in Go-land That becomes a bit problematic if the C-land use is for a long-running process - you need a go object that owns the memory that has a lifetime that (at least) matches the lifetime of the C code execution.
    - danieldk 11y ago
      Currently, yes. Once Go has a moving garbage collector (soon-ish), no. A moving garbage collector can move objects around. This would invalidate pointers in C, since the GC can run concurrently with C code (even if it didn't, it would invalidate pointers to object allocated in Go in C structs). To make things work, you have to allocate date used in C in C and pass Go variables only by value.
blt 11y ago
some GC languages pause garbage collection while calling out to native code. under this scheme it's no problem to call C to do something like multiply matrices or compute hash functions. the problems come when you want the C code to call back into GC code, for example an event loop or a huge computation that wants to report its progress. it's hard. mixing manual and automatic memory management is tricky.

Daemon404 11y ago

Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack address change now?

danieldk 11y ago
The Go spec does not contain the stack or heap, so I guess that in principle it's fair game for the collector to relocate it in memory. In some future version it's only safe to use memory in C-land that was allocated in C-land.
- AnimalMuppet 11y ago
  Wouldn't it be safe to use in C-land as long as you kept a reference to it in Go-land? Something like: Create memory in Go-land Use memory in C-land Dispose of reference to memory in Go-land That becomes a bit problematic if the C-land use is for a long-running process - you need a go object that owns the memory that has a lifetime that (at least) matches the lifetime of the C code execution.
  - danieldk 11y ago
    Currently, yes. Once Go has a moving garbage collector (soon-ish), no. A moving garbage collector can move objects around. This would invalidate pointers in C, since the GC can run concurrently with C code (even if it didn't, it would invalidate pointers to object allocated in Go in C structs). To make things work, you have to allocate date used in C in C and pass Go variables only by value.

blt 11y ago

some GC languages pause garbage collection while calling out to native code. under this scheme it's no problem to call C to do something like multiply matrices or compute hash functions. the problems come when you want the C code to call back into GC code, for example an event loop or a huge computation that wants to report its progress. it's hard. mixing manual and automatic memory management is tricky.