[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] thread scheduling: how about an idle-thread-hook?
From: |
chicken-users-admin |
Subject: |
Re: [Chicken-users] thread scheduling: how about an idle-thread-hook? |
Date: |
Fri, 9 Aug 2002 16:38:43 +0100 |
User-agent: |
Mutt/1.2.5i |
> 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