No. Nim channels are for inter-thread communication within the same process, and they perform a deep-copy of messages. Fusion channels are a different beast. They're kernel objects that require syscalls to create/open/send/recv/close. In order to achieve zero-copy, the channel heap needs to be in user-space, but managed by the kernel. It's kind of similar to shared memory on POSIX, but has message passing semantics, rather than arbitrary read/write from/to shared memory. And since Fusion is a single address space operating system, I have the luxury of passing pointers (to data on the channel heap) directly between tasks without resorting to (de)serialization. Protection is achieved through page table mappings, where e.g. the sender would have read/write access to the channel heap, but the receiver has read-only access to the same memory.
As for your case, I understand the need to avoid locks. In my case, the channel is implemented as a queue of messages, which is implicitly synchronized between tasks. Currently it's implemented using a blocking queue, since I want to put senders/receivers to sleep when the queue is full/empty, respectively. The API does support a no-wait option, but I'm not currently using it.
There will be a lot to write about once I'm past this point :)