[cl-muproc-devel] threads nature and CVS access

[Klaus Harbo]

Anton V. Belyaev wrote:
> Hi guys!
>
> I have a couple of quick questions:
>
> 1) Does project have CVS?
>
> 2) What is the nature of threads? Erlang "threads" are not mapped 
> one-to-one to system threads. Is it true for cl-muproc?
> _______________________________________________
> cl-muproc-devel mailing list
> cl-muproc-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cl-muproc-devel
Re CVS:

We use darcs for version control.  There is no publically accessible 
repository at this time; if there is strong demand for this, I believe 
we could add that some time (I am not entirely sure what that would entail).

Re threads:

cl-muproc relies on the implementation's process implementation for 
muprocs.  In current (v4) Lispworks this means 'green' (non-OS) threads, 
whereas in SBCL and the upcoming v5 of Lispworks, for example, it means 
native threads.  cl-muproc does not explicitly specify the 
implementation/representation of muprocs -- both can work.

I do not think anything in cl-muprocs precludes developing alternative 
muproc implementations which could be more efficient under some 
circumstances.  Erlang processes are extremely efficient, LW's processes 
much less so.  It could be an interesting project to see if similar 
efficiencies could be achieved in some CL implementation by 
'hand-coding' a muproc implementation in Lisp (I have not given this any 
serious thought, perhaps that is not a realistic proposition). 

The efficiency of muprocs is quite important, I think, since it 
ultimately impacts your system design -- can you scale by spawning 
additional muprocs, or do you have to use some other means?  A few 
hundred muprocs (which is what LW and Allegro can realistically support 
at this time) does not offer sufficient scalability, if we just want to 
scale by spawning new muprocs.  In the system we're working on at Mu, we 
use state machines inside muprocs to enable a single muproc to keep 
track of many processes; it works and performs quite well but the 
downside is the added complexity of coding state machines.  Ultimately, 
I believe we will scale by distributing the load across several Lisp 
images running on multiple hosts.

HTH,

-Klaus.