[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ethreads: event-driven cooperative threads

From: Andy Wingo
Subject: Re: ethreads: event-driven cooperative threads
Date: Thu, 17 Jan 2013 10:58:31 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)


Catching up on old things...

On Mon 02 Apr 2012 17:25, address@hidden (Ludovic Courtès) writes:

> Andy Wingo <address@hidden> 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]
>   [1]

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.

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]