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