Re: [Boost-users] boost coroutine status

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