[cl-muproc-devel] threads nature and CVS access
klaus at mu.dk
Thu Jul 6 19:16:58 UTC 2006
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
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).
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.
More information about the cl-muproc-devel