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

[Jörg F . Wittenberger]

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

/Jerry

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