guile-devel
[Top][All Lists]
Advanced

[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)

Hi!

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] 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/



reply via email to

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