[Prev][Next][Index][Thread]

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



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.