[cl-muproc-devel] Some suggestions

[Klaus Harbo]

Jochen Schmidt wrote:
> Hello,
>
> First I want to thank for making available CL-MUPROC; I think that 
> Erlang style concurrency is a very interesting and valuable addition 
> to Common Lisp. Some people have already pointed out that CL-MUPROCS 
> process implementation is to heavy-weight for Erlang style 
> concurrency. While I think that this is true, I do not see it as a big 
> problem. Even if CL-MUPROC will not get such more scalable process 
> implementations it will be a good API for doing multiprocessing in CL 
> (instead of using the MP facilities of the different Lisps directly).
I agree on both points.  However, I think there are real implications of 
not being able to spawn as my muprocs as you like.  In Erlang, you can 
realistically design a system which spawns a process for each task the 
system needs to handle.  In cl-muproc, if you're concerned with 
scalability of your design, that is not a viable approach.  You have to 
think differently; at least that's what I have been doing.  The system 
we're building, I have stayed with a static number number of muprocs and 
use finite state machines inside muprocs to scale task-wise.  This 
approach has worked quite well, I think, although I would really like to 
have the scale-by-spawning option available as well.  Unfortunately, to 
my knowledge no Lisp implementation can offer really large numbers of 
threads.  I have experimented at little bit -- Allegro has a hard-coded 
limit of a few hundred processes/threads (I forget what term they use), 
Lispworks starts slowing down something awful on my AMD64 machine once 
you have spawned some 500 threads or so.  

>
> I personally think that the muproc-* prefixes are unnecessary. 
> Particularily names like MUPROCS-SEND or MUPROCS-RECEIVE might be 
> better spelled MUPROCS:SEND or MUPROCS:RECEIVE with the option to 
> import this symbols into an application package and then just use SEND 
> and RECEIVE. Using packages this way would also enable to use your own 
> prefixes by just adding appropriate nicknames to the MUPROCS package 
> (MU:SEND, MU:RECEIVE).
>
I know what you mean.  Actually, I do not have strong feelings on this 
point, except that I think it is an issue of balancing 'name space 
clutter' against long names.  Personally, I like to import exported 
symbols of the libraries/packages I use into my own packages.  
Obviously, I don't want them to clash with symbols from other packages.

When I started muproc I simply had 'send' and 'receive' (which are now 
mumsg-send and mumsg-receive, btw), but at some point I felt that these 
terms were pretty generic, and that the danger of clashes with other 
libraries was large enough to consider.  To be a 'good Lisp citizen' I 
felt that muproc shouldn't claim that piece of name space for itself, so 
I decided that muproc-send and muproc-receive (and subsequently 
mumsg-ditto) would be better, and for consistency that other exported 
symbols should have appropriately prefixed names as well.  However, if 
consensus is that eliminating the prefixes is preferable, I could 
certainly live with that as well.  I am certainly susceptible to the 
argument that muproc:send is not much more typing than muproc-send! ;-)

> ciao,
> Jochen 
-Klaus.