Subject: Re: [Boost-users] boost coroutine status
From: Nat Goodspeed (nat_at_[hidden])
Date: 2009-04-30 17:33:52
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