On 22/06/13 18:47, Ondrej Kupka wrote:
I've been contributing to gozmq a little bit recently, trying to implement some basic zero copy and stuff, and I must say that there will always be problems with data ownership between C and garbage-collected languages I think. Like to do zero copy, you pass the data to libzmq, which basically takes the ownership, but Go has no idea about what is happening there, so if you don't make sure that the data is reachable from Go as well, it will be GC'd and it will end up badly, because libzmq will then try to free memory that is no longer there. So having everything written in Go (or put any GC'd language here), this is no longer an issue because Go manages all the memory.
Zero copy is an ugly beasts as it requires the lowest layer of the stack (network driver) and the highest layer of the stack (application) to share the allocation mechanism. E.g. network driver allocates data in physical memory and passes that to the application. Application than has to free the physical memory instead of a simple free(). Same applies to e.g. IPC via shared memory.
With nanomsg the problem gets even worse than with ZeroMQ. ZeroMQ supports only a quasi-zero-copy system where data are guaranteed not to be copied in the user space. Copying to/from the kernel space and then copying to/from the NIC is allowed. nanomsg, on the other hand, already has an infrastructure for true zero-copy, i.e. copying data directly from remote application to local application, by-passing the CPUs etc.
All in all, zero-copy never plays well with higher-level languages with built-in garbage collection and thus, if implementing nanomsg in Go, I would rather avoid zero-copy entirely.
Martin
