Hi! Catching up on old things...
On Mon 02 Apr 2012 17:25, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo <wi...@pobox.com> skribis: > >> I pushed an experimental branch recently, wip-ethreads. It implements >> user-space cooperative threads that yield when they would otherwise >> block or sleep. It seems to be useful for servers. > > Interestingly, user-level threads + port wrappers is the same strategy > as GNU Pth. Indeed, yes. > It has the advantage of avoiding IoC, while nicely solving some of the > problems associated with native threads (state mutations are atomic, > ‘fork’ can be used, etc.), but it has shortcomings. > > First, if user code ends up using a “raw” port, or does some other > blocking call (even indirectly, via a library), the whole program is > blocked. Yes. This is also the case for computations that busy-wait, though we can schedule asyncs if needed, but that has its own set of problems of course. > Second, if at some point you want to start using more than one core, > you end up building an N×M thread library, which is a nightmare [0, 1]. > > [0] http://www.akkadia.org/drepper/glibcthreads.html > [1] http://www.akkadia.org/drepper/nptl-design.pdf This sounds damning, but is is still true? Go's "goroutines" seem to be scheduled on an MxN thread library, and I haven't heard complaints about that. We don't have the same constraints regarding signals and POSIX, for example. I'll poke around and see what the state of the art is. > So, it seems cool to me, and it’s great that it addresses the > web-server-that-forks use case. However, I fear that it’s not > sufficiently generalizable. > > WDYT? Basically I don't know. I enjoyed programming with it, and the kinds of programs you could make with it, but there are many unknowns. In the Guile context, if we were ever to merge it I think we'd have to have a better story regarding integration with "native" ports. Andy -- http://wingolog.org/
