

Show HN: Go channels as a C library (with Obj-C wrapper) - davekeck
https://github.com/davekeck/eb_chan

======
davekeck
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.

Feedback appreciated!

------
richo
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.

~~~
davekeck
Thanks for the feedback!

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.

Thanks again!

~~~
richo
Cheers for the response.

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?

