[cl-muproc-devel] Some suggestions

[Jochen Schmidt]

Am 16.05.2006 um 20:13 schrieb 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 imagine how worker-thread scheduling is done in allegroserve and I  
think it would look alot better using an API like CL-MUPROC.

>> 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.

Well - this is what packages are made for: avoiding symbol-name clashes
I personally make a distinction between implementation packages and  
interface packages. In implementation packages I collect the symbols  
of different interface packages to implement a particular module. The  
symbols of the interface of the module itself are imported too from a  
separate interface package. Some macrology and package hacking makes  
this all a quite straightforward job.

> 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! ;-)

But MU:SEND or even M:SEND is significantly shorter! :-)
Quite a while ago I was used to use class prefixes in all generic  
functions after reading http://cybertiggyr.com/gene/www.lisp-p.org/ 
htdocs/80-closminded/ I decided to drop the prefixes on accessors and  
on generic functions.

ciao,
Jochen