Re: [Boost-users] boost coroutine status

Subject: Re: [Boost-users] boost coroutine status
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-04-30 19:05:20

On Thu, Apr 30, 2009 at 3:33 PM, Nat Goodspeed <nat_at_[hidden]> 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?

Yep, and a lot of scaffolding, it is not an easy-drop in thing, but it
ran fast and supported an Actor based programming model (which is what
I was going for, which means that 10k little coroutines may be a small
number in many cases, fibers choke and die).  A lot of work to program
a new coroutine, but it worked well.  Not something anyone else would
want to use though (although much of the scaffolding that had to be
repeated could be done using templates now that I know those well
enough know).

On Thu, Apr 30, 2009 at 3:33 PM, Nat Goodspeed <nat_at_[hidden]> wrote:
>>> 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.

You should try the Actor Programming Model, pretend there is no global
state (unless you know for certain of no issues), create an atomic CAS
based scheduler to switch between the coroutines/actors, etc... It
scales well, works on multiple threads (with actors able to be
switched between them easily), can even scale across a network, the
scaling is pretty arbitrary, very nice way to program (although it
requires a few changes in how you normally think to program things).

On Thu, Apr 30, 2009 at 3:33 PM, Nat Goodspeed <nat_at_[hidden]> wrote:
>>> 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.

Yea, and they screwed it up.

I am a bit bitter at threads, tried using them for a few weeks (many
years ago) until I finally figured out that they were not allocated
the memory they should have been, my solution ended up being faster
too (but as stated, horrible horrible amount of scaffolding, not
anything most people would want to inflict on themselves).

Because C++ is horrible at this stuff, I have been making my own
language, trying to keep it low-level like C, just no global state,
etc... and completely Actor based (C with Actors?), built on top of
LLVM, coming quite wonderfully right now actually.