[Top][All Lists]

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

Re: [Chicken-hackers] poll(2) with chicken: works - sort of

From: Jörg F . Wittenberger
Subject: Re: [Chicken-hackers] poll(2) with chicken: works - sort of
Date: 14 May 2012 21:12:45 +0200

On May 14 2012, Moritz Heidkamp wrote:

Jörg F. Wittenberger <address@hidden> writes:
Anybody interested to pull this into the official chicken core?

That's definitely interesting. I wonder if it would be possible to
provide hooks in the core so that the scheduler can be replaced from
user code?

I'd really like it to be that way.  Personally I'm not a big fan
of srfi-18 style threads.  In practice I use an IMHO more Schemish
set of threading primitives[1] (build for the sake of being standards
based on top of s18, but I'm sure I could do them much better
at the level of switching continuation.

Funny enough: here the title of my master thesis ('93):
"process scheduling at the application layer".

That way it would be possible to use even more efficient OS
specific APIs like epoll. Or perhaps the whole issue could be
side-stepped by using something like libev instead?

These would be the interesting consequences of having an
stable API and no more in the core.  (I would not love to
have an general dependency on libev for chicken.) We could have a bunch of srfi-18 (as is, modified,
build on libev or it's alternatives) plus some alternate
thread interfaces.

best regards


[1]:  I'm using e.g. "!apply", "!map" and "!mapfold" where
!apply would create and immediately join (possibly with
timeout) a thread to apply the function to it's arguments.
!map does what map does, just one thread per element in paralles
and !mapfold accumulates the results in unspecified order
(as available) possibly only waiting for an specified number of
map results to become available.

reply via email to

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