Any chance the package in the vault could be updated with these patches?. Would it be possible to include the html version of thedocumentation in the package in the vault as well? Robert Ramey Nat Goodspeed wrote:

Robert Ramey wrote:

...

a) When I try and build it, I get ConvertFiberToThread which looks to me that there is some bjam magic missing.

It's not bjam -- the right declarations can be accessed from -- but they're hidden unless you write:

#define _WIN32_WINNT 0x0400

before that #include. Please see the boost-coroutine2.patch attachment, notably for boost/coroutine/detail/context_windows.hpp, late in this thread: http://groups.google.com/group/boost-list/browse_thread/thread/d4f8e90ecab8d...

...

Anyone having information on this topic is encouraged to bring me up to date.

I'm not yet using it in production code -- but I intend to. The mail thread cited above mentions that I was able to run one of the example programs on Windows XP Pro, Mac OS X 10.5, 32-bit Debian sarge and 64-bit Debian etch.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 08 April 2009, Robert Ramey wrote:

Any chance the package in the vault could be updated with these patches?. Would it be possible to include the html version of thedocumentation in the package in the vault as well?

I don't do much windows development, but I don't think a coroutine header file is supposed to redefine _WIN32_WINNT. Spitting out an error message saying it requires _WIN32_WINNT >= 0x400 seems more appropriate.

Nat Goodspeed wrote:

...

It's not bjam -- the right declarations can be accessed from -- but they're hidden unless you write:

#define _WIN32_WINNT 0x0400 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknc63QACgkQ5vihyNWuA4UPNwCeMD7uRaO2RsryBb4nGu1QAwX8 a84AnR4QYrJZ+4/qvImI5U3JU97OTXEJ =eILp -----END PGP SIGNATURE-----

Robert Ramey wrote:

Any chance the package in the vault could be updated with these patches?. Would it be possible to include the html version of the documentation in the package in the vault as well?

http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-coroutine-2009-04-29.tar.gz&directory=Concurrent%20Programming& I added a NEWS file sketching the changes. And -- as requested -- I've tossed in the documentation .html files from http://www.crystalclearsoftware.com/soc/coroutine/index.html .

On Thu, Apr 30, 2009 at 8:56 AM, Nat Goodspeed wrote:

Nat Goodspeed wrote:

...

Robert Ramey wrote:

...

Any chance the package in the vault could be updated with these patches?. Would it be possible to include the html version of the documentation in the package in the vault as well?

Let's try that again: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-coroutine-2009-04-30.tar.gz&directory=Concurrent%20Programming&

As soon as I #included coroutine headers in a second .cpp file on Windows, I ended up with duplicate-symbol link errors. Maybe Giovanni Deretta hadn't gotten beyond single-source test programs. Fortunately the fix was straightforward.

I looked at this library a few years ago before I wrote my own (for a windows system), 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. 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.

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

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