Robert Ramey wrote:
OvermindDL1 wrote:
I looked at this library a few years ago before I wrote my own (for a windows system),
I'm curious how you did that? Assembly code?
and the big problem I saw with it was that it uses fibers on windows. Fibers have this little problem, if you say you need, say, 20kb for the fiber stack, it still allocates as much memory as a thread uses (4megs by default I think), meaning if you try to create 10k of these little buggers, you run out of memory well before that. Made this library rather worthless for my use.
Heh, my own use case involves a far smaller number of coroutines, so this isn't such a problem from my POV.
If it really wants to be used for a good coroutine based paradigm, then they need to get rid of the fiber usage on the win32 side.
One of the MS blogs I read about fibers (sorry, don't have the link ATM) asserts that they introduced fibers because many many people rolled homebrew solutions that almost (!) covered all the gotchas. I don't yet have an opinion of my own, and am simply hoping that fibers will work well enough for my purposes -- since that's the implementation I have on hand.
Here is a set of enhancements which would be welcome: a) implemention of the coroutine switch for other platforms. Currenlty linux and windows are implemented. b) a possible alternative implemenation of coroutine switch for windows which doesn't depend on fibers. I have one that I've used for many years. Of course it's in assembler. I'm sure this is doable.
I guess including alternative Windows implementations would allow each coder to pick the set of tradeoffs that best fits his/her own use case.
c) I would like to see the lower level implemenation selectable at compile time between different implementations - including one based on threads so that one would have the same interface for a multi-threading/multicore environment.
In my own case, I need to distinguish between "user threads" and "kernel threads." When you start with a large legacy app and want to run some existing code on a separate thread, I know of no way to guarantee the new thread won't interact badly with the rest. Coroutines, in contrast, avoid introducing potential new race conditions. I'd be alarmed if someone tried to run our coroutines on concurrent kernel threads. It might be safer to write new code using a threading API, with the option to switch to a "user thread" underlying implementation. You might be interested to check out the coco library: http://www.mr-edd.co.uk/?page_id=91