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!
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!