[plt-scheme] Threading vs. System Threads

At Wed, 12 Feb 2003 11:10:59 -0600, Robert Bruce Findler wrote:
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> How do you handle killing of threads? That is, in the face of
> custodian-shutdown-all or kill-thread, can messages appear multiple
> times or can internal queues get put into bad states (deadlock)?
> 
> Robby
> 

I suspect ending up in a bad state will be much less of a problem
in a cooperative multitasking system.  If nobody can interrupt your
thread until it yields, nobody else can be running to kill your thread
at an un-opportune moment.

Robby does raise a good point, though.  Now that I think about it,
the channels used in the Web server (and by John Clements?) may have a
bug in this regard.  If the custodian shuts down in the middle of enqueuing or
dequeueing a message, the receiver or subsequent senders could get stuck.
In the server's case I don't think this is very likely since a servlet
sends a response message on a channel right after processing a request, and
before processing a request its timeout is reset to a few days or so.
Thus the race condition seems unlikely unless the servlet vastly exceeds
any mortal's patience while waiting for their browser to respond.
Still, I would feel better if I fixed the channel.ss library.

I really like Erlang's paradigm.  I'm a bit torn between its model
of sending lots of different types of messages to a thread and letting the
thread separate the jumble by pattern matching verses sending different
types of messages to different channels and letting threads choose what
to listen to when by calling receiving on the channels they are interested
in at the moment.

Paul


> At Wed, 12 Feb 2003 12:07:52 -0500 (EST), Gregory Cooper wrote:
> >   For list-related administrative tasks:
> >   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> > 
> > 
> > Actually, what I've been working on is a thread communication library for
> > PLT Scheme.  My goal is to provide the essence of Erlang-style processes
> > and message-passing, which involve the following three constructs:
> > 
> > (spawn expr ...)
> > 
> > creates a new thread to evaluate the given expressions, returning the
> > thread's id, which can be used as a destination for messages;
> > 
> > (! tid val)
> > 
> > sends val to tid; this call returns (void) immediately, and the message is
> > queued in tid's mailbox until tid is ready to process it;
> > 
> > (receive [after timeout timeout-expr ...] ; (optional)
> > 	 [pat expr ...]
> > 	 ...)
> > 
> > blocks the current thread until either the timeout (if given) expires or
> > the thread receives a message matching one of the given patterns; the
> > patterns can bind variables for use in the corresponding expressions,
> > which are evaluated upon receipt of the message.
> > 
> > I have an implementation of this interface that uses MzScheme's
> > (preemptive) threads and performs quite well in general.  On my machine,
> > for example, I can create several thousand threads in DrScheme without
> > straining the system much.  However, in a restricted setting, I've found I
> > can use a custom, cooperative threading model to improve performance
> > significantly.  In particular, I can cut the spawning time by a factor of
> > 25, reduce the resource requirements by a factor of 50, and also modestly
> > reduce communication time (by up to a factor of 2).
> > 
> > Greg