eb_chan is a C library (supporting OS X, iOS, and Linux) that provides a complete implementation of the Go channel primitive. Also included is an Objective-C wrapper which allows for a convenient select-statement syntax using blocks.
eb_chan provides the full range of functionality of Go channels, including blocking and non-blocking selects on an arbitrary number of sends and receives.
Two focuses of this project are to maximize throughput and minimize resource consumption. To maximize throughput, eb_chan includes a fast-path (to avoid making system calls) which consists merely of acquiring a spinlock and modifying a structure. To minimize resource consumption, eb_chan avoids using scarce resources, such as file-descriptor-based primitives like UNIX pipes. Instead, eb_chan uses Mach semaphores (semaphore_t) on Darwin, and POSIX semaphores (sem_t) on Linux, both of which can be allocated on the order of 10^5 without hitting resource limits.
Uhhh, except that this in no way actually implements CSP, given that more than one actor can just hang onto a resource despite having passed a pointer to someone else?
Who's meant to deal with freeing? Do you necessitate GC?
It's also fairly distasteful that all type safety is discarded.
I didn't mean to imply that this project even remotely implements CSP. What I mean to say is that this library is an implementation of the channel primitive associated with CSP. I mentioned CSP to give the project some context outside of Go.
And yes, the pointer can still be mucked with after sending over an eb_chan; perhaps I should call them "cooperative channels," meaning the sender agrees to cooperate with the receiver and not modify the data after sending.
> Who's meant to deal with freeing? Do you necessitate GC?
eb_chan instances are reference-counted, so any entity that needs to ensure its existence should retain the channel, and release it when it no longer requires its existence.
I decided to make eb_chan a reference-counted type instead of using an alloc/free pattern because the former is much more flexible in a multithreaded environment. Furthermore, the RC pattern is a superset of the alloc/free pattern, so if you prefer to use it as such, just never retain the instance after creation.
> It's also fairly distasteful that all type safety is discarded.
I agree, but so far I haven't found a better way given that the target language is C. I've thought about using some preprocessor magic to allow defining of custom eb_chan types, I may have to revisit that.
My question about deallocation was regarding the resource though, not the channel.
Honestly, while from a best practice sense it shouldn't be too hard (You need to either send or free a resource when you're done with it), in practice my intuition is that codebases using this will be rife with exciting use after free bugs.
Seperately, have you done any testing to see what valgrind makes of it?
eb_chan provides the full range of functionality of Go channels, including blocking and non-blocking selects on an arbitrary number of sends and receives.
Two focuses of this project are to maximize throughput and minimize resource consumption. To maximize throughput, eb_chan includes a fast-path (to avoid making system calls) which consists merely of acquiring a spinlock and modifying a structure. To minimize resource consumption, eb_chan avoids using scarce resources, such as file-descriptor-based primitives like UNIX pipes. Instead, eb_chan uses Mach semaphores (semaphore_t) on Darwin, and POSIX semaphores (sem_t) on Linux, both of which can be allocated on the order of 10^5 without hitting resource limits.
Feedback appreciated!