Re: [Chicken-users] thread scheduling: how about an idle-thread-hook?

[chicken-users-admin]

> I'd very much like to work without threads for my application and
> stick to a low level select(2)/poll(2)/kqueue(2) style mechanism. I
> intend to build a small event driven programming library on top of the
> underlying socket, POSIX and select/poll mechanisms and work that
> way.

Me too (and that's what multiplex.scm is intended to be): well, the
only real problem I have with threads is their
preemptiveness. Otherwise they're just "upside-down" event-driven
systems, to me :-) ... call/cc is a wonderful equalizer ...

Originally, when implementing multiplex.scm, I started off using
call/cc to build coroutines or pseudo-threads for blocking on I/O, but
the whole thing of exception-handlers and dynamic-wind got pretty
hairy after a while.

Looking at the way context-switching is implemented in Chicken made me
abandon my own attempts to implement something similar in "userland";
using call/cc means you've got all that dynamic-wind overhead, using
the native context-switching mechanism is lighter-weight...

Once I'd settled on that, the only remaining issue I had with
Chicken's threads is then that they are preemptive. If I could have a
nice API for making them into non-preemptive threads (ie. turning off
the timeslicer), I'd be happy: then I could use multiplex.scm,
socket.scm and plt-net.scm together, and not have to worry about
locking issues: essentially I'd be programming in an event-driven
style that looked like threads. To me, that's the best of both worlds
(because state machines get very complicated very quickly)...

Actually, even with preemptiveish Chicken threads, I think I'll be
okay: I think I'll end up using mailboxes (from multiplex.scm) a lot,
and use message-passing for thread synchronisation... like Erlang
does, in a way.

> That is not to say that I oppose having other mechanisms for people
> who want threads -- just that some of us do not want to be forced to
> use them to multiplex I/O.

I agree - I prefer event-driven programming by far.

Any suggestions on how to avoid the whole srfi-18 thing, while keeping
the correct exception-handler and dynamic context installed in the
correct place, without losing reasonable efficiency? It's a tough one
:-(

(An issue similar to this seems to have been what killed off the
fluid-let srfi...)

Tony
-- 
Monkeys high on math -- some of the best comedy on earth
        - Tom Lord, regarding comp.lang.scheme