[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]
- To: firstname.lastname@example.org, email@example.com
- Subject: Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]
- From: firstname.lastname@example.org (kr)
- Date: kr\r\essword:, 27 Jun 1995 11:17:39 -0800
I am forwarding the followng note, because I believe that both GCL and
CLISP would benefit from a multithreading facility, one that hopefully is
>Date: Tue, 27 Jun 1995 09:12:17 -0400
>To: email@example.com (kr)
>From: JCMA@ai.mit.edu (John C. Mallery)
>Subject: Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]
>Cc: firstname.lastname@example.org, email@example.com
>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
>Thus, what you would like it a scheduler and stackgroups for each thread.
>been suggested that closures could be used to fake stack frames, but I
>experience with this.
>You need to understand the serial, single thread assumptions built into the
>networking code and work around them. Basically, this means avoiding
>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
>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