[Prev][Next][Index][Thread]
Re: Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]
> Subject: Issues for Multithreaded Ports [formerly: Re: cl-http for clisp]
> Cc: deilmann@router.leat.ruhr-uni-bochum.de, www-cl@ai.mit.edu
> Sender: owner-www-cl@ai.mit.edu
> Content-Length: 2123
>
> 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 ?
>
I have been looking at the CL-HTTP code for portability, and
I would recommand using the CLIM "standard" for both resources
and multi-processing (all of us should also *encourage* our Lisp
vendors to follow CLIM2.0 interface description instead of providing
their own in different packages).
CLIM2.0 defines in the CLIM-SYS package a small set of process
and resource primitives that could be used by all of us instead
of incorporating every implementation specific variations...
Perhaps the CLIM-SYS definition of MAKE-PROCESS could also be
extended to pass OPTIONS such as :quantum and :priority.
For example the RESOURCE package on the MAC (CL-HTTP) could
advantageously be called "CLIM-SYS" and with minor changes
provide an interface to resources and processes compatible with
CLIM. Then any CLIM2.0 implementation would provide a compatible
ground to port CL-HTTP, you may get more contributions
to CLIM interface enhancements to CL-HTTP as well (if it's easier
to port to CLIM2.0 implementations of Franz and Harlequin).
>
> 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.
>
Yes, this is possible I have an implemention of a "MINI-PROCESS" scheduling
based on closures that will port to any CL implementations. However this is
not directly compatible with CLIM2.0 "CLIM-SYS" and requires careful
extra variable declarations when declaring processes. This approach will
however work identically on MCL, ACL for Windows and UNIX. For example
you can have multiple processes competing for multiple sockets (port) from
Winsock under windows as long as they are non-blocking...
[There is however possible interferences between a closure based scheduler
and any existing MP scheduling (e.g. Franz or Harlequin MP under UNIX).]
Here is a topic of discussion with Lisp vendors at LUV'95 in Cambridge (August):
I recommend Lisp vendors should provide "CLIM-SYS" as a minimal common
process and resource package everywhere, otherwise porting CL applications
remains more painful that desirable. In the mean time portable system developped
using CL (like CL-HTTP) could provide there own "CLIM-SYS" (with or without CLIM).
>
> 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.
>
Precisely, if a multithreaded implementation of CL-HTTP is written
using the simple process primitives defined in CLIM-SYS, then a single
threaded implementation of CL will still run, only as a single thread
without change to the code. I don't think multiplying version of the
CL-HTTP multi-threaded code for every single type of multiprocessing
implementation will help anyone (Symbolics, Franz, Lucid, Harlequin, MCL
and ACLPC are all different in this matter). Already it seems that the
MCL and Symbolics implementations provided are miles appart in this matter.