Q: few questions
Closed this issue · 3 comments
Q1: how different it is from libcoro?
Q2: not sure you can use malloc() to allocate memory for stack -- aren't there some stack alignment requirements that malloc() can break?
Q1: libcoro is released under the BSD license, while I will release this under the MIT license, and I will also release it under whatever other license that supports it's inclusion into Ruby/MRI.
Q2: The alignment requirements are taken care of in the specific implementations. I haven't put much effort towards this yet. However, you shouldn't really use malloc to allocate stacks, you should use mmap and mprotect. It's just an example for the README. Feel free to make it better.
Q1: I thought BSD license is even more permissive than MIT... It isn't?
In any case -- I suggest broowing as much as you can from libcoro. :-) It has been used in many projects for a very long time and is proven to be very good.
Q1: The MIT is more permissive, since it doesn't specifically require attribution in compiled binaries.
I don't plan on borrowing much from libcoro, because that would be infringing on that IP - I don't think it's fair to take libcoro, put a new name on it and change the license.
In any case, I had issues with libcoro - the latest version of the code is broken (it won't compile due to issues with the preprocessor). Additionally, I don't think there is any reason to support the slower variants that libcoro implements - they are interesting but pointless in any real world code.
libcoro by default is also not thread safe. Making it thread safe is possible using thread_local but it's a hack that should be entirely unnecessary. This library implements an objectively better API which avoids this problem and in theory should be slightly more efficient.
Finally, I think that putting every implementation into a single .c file is too much. I had issues with the windows implementation, and the implementations for architectures which are untested. That bothers me a lot.
In this project, I plan to implement every architecture independently. I might end up back tracking on this, but so far it's been a very good approach since I can test the different architectures more easily, and once they are tested and confirmed working, they are set in stone - the files would never need to be updated.