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

From: [email-masked] (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
mutually compatible.
===========================================================================
>Mime-Version: 1.0
>Date: Tue, 27 Jun 1995 09:12:17 -0400
>To: [email-masked] (kr)
>From: [email-masked] (John C. Mallery)
>Subject: Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]
>Cc: [email-masked], [email-masked]
>
>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

---

From: [email-masked]
Date: Wed, 28 Jun 1995 09:52:44 --100

ECoLisp (ECL), a derivative of KCL, has multithreads.
If you are interested, you can get it from:

 - ftp.icsi.berkeley.edu [128.32.201.7], directory /pub/ai/ecl
 - ftp.di.unipi.it [131.114.4.36], directory /pub/lang/lisp

ECL is based on a Common Runtime Support (CRS) which provides basic
facilities for memory managment, dynamic loading and dumping of binary
images, support for multiple threads of execution.  The CRS is built
into a library that can be linked with the code of the application.
ECL is modular: main modules are the program development tools (top
level, debugger, trace, stepper), the compiler, and CLOS.  A native
implementation of CLOS is available in ECL: one can configure ECL with
or without CLOS.  A runtime version of ECL can be built with just the
modules which are required by the application.

ECL runs on:

 - Sun workstations with SunOS 4.x or Solaris 2.x
 - Silicon Graphics with IRIX 4.x
 - NeXT with NeXTStep 2.x
 - IBM PC with DOS/go32
 - IBM PC with DOS/emx
 - IBM PC with Linux 1.0

-- Beppe