Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]

[kr@shell.portal.com (kr)]

I am forwarding the followng note, because I believe that both GCL and
CLISP would benefit from a multithreading facility, one that hopefully is
mutually compatible.
===========================================================================
>Mime-Version: 1.0
>Date: Tue, 27 Jun 1995 09:12:17 -0400
>To: kr@shell.portal.com (kr)
>From: JCMA@ai.mit.edu (John C. Mallery)
>Subject: Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]
>Cc: deilmann@router.leat.ruhr-uni-bochum.de, www-cl@ai.mit.edu
>
>At 4:50 AM 6/27/95, kr wrote:
>>At 23:44 6/26/95, John C. Mallery wrote:
>>>A port reduces to providing the network interface and multithreading.
>>
>>Does a capsule summary exist regarding the requirements and interface to
>>the multithreading facility ?
>
>The mac port is quite parsimonious.
>>
>>Would it be difficult to emulate (or implement) multithreading in GCL or
>>CLISP ? What would be required ?
>
>Singlethreading will suffice until after you get the network interface up
>and fully debugged.
>Then, you can introduce multithreading, and debug that.
>
>Karsten Poeck implemented a poor man's multithreading for the MAC running in
>MCL 2.0.1 based on MCLs periodic tasks. It is found in http:mac;contributions;
>
>The main problem occurs if you get an error and don't have a stack. Not so
>nice.
>
>Thus, what you would like it a scheduler and stackgroups for each thread.
>It has
>been suggested that closures could be used to fake stack frames, but I
>don't have
>experience with this.
>
>You need to understand the serial, single thread assumptions built into the
>lisp or
>networking code and work around them.  Basically, this means avoiding
>collisions
>across threads. Garbage collection is a nasty area for possible collisions.
>
>In the networking code, a series of conditions are handled in the Lisp
>Machine and MAC versions.
>One should arrange to detect and signal these.  The mac version provides
>source code for all
>of these in http:mac;server; tcp-conditions. The availability of these
>conditions will definitely
>help  with poor man's multithreading.
>
>In general, it will help if the developers of the Lisp contribute to adding
>real threads with
>their own stackgroups.  Source code access will be essential to get robust
>threading
>to work.
>
>The bottom line, though, is that you are better off getting a single
>threaded server running
>first, and then, working on arranging for multithreading.  That way, you
>will have something
>running as soon as you get the network code up and it will be a server
>which is prefectly usable
>with single-threaded clients.  Once you get that far, it will be easier to
>get help with
>multithreading.
>

Greetings
Markus Krummenacker