[cl-muproc-devel] Integration of OpenMCL and SBCL/CMUCL patches in darcs repo -- testing requested

Klaus Harbo klaus at mu.dk
Mon Jul 10 09:41:43 UTC 2006

I have now integrated the latest patches from Rudi and Vladimir.  Tests pass on 
Lispworks, and I have made no real changes to any files in 
implementation-specific layer (well, I had to reintroduce %with-lock% in 
muproc-lispworks.lisp, but that should be relatively safe!).

Vladimir has made some changes to muproc.lisp which are not related to porting 
per se, the most significant of which I believe is the introduction of a 
separate lock for *muproc-errorstream* and use of a muproc-specific lock for 
things which are not genuinely global (for which %with-exclusive-access% is 
still necessary, of course).  I have accepted all these changes, which I believe 
to be sound.

I do think, that perhaps we should abstract the muproc-specific locking further 
and possibly eliminate the use of the process plist; i.e. wouldn't an explicit 
data structure protected by this lock be better than using process plist?  I 
think so.  The data could be introduced in the progv form in muproc-spawn and be 
protected by the lock already introduced by Vladimir.  That way we're safe from 
updates performed by other part of the Lisp image (anyone can use the process 

I have not created a new release yet, as I would really like Rudi and Vladimir 
(or anyone, actually) to test that the CMUCL, SBCL and OpenMCL support works 
after my changes.  If you have time, please do!

The latest version is available from the public repository 

Rudi Schlatte wrote:

 > I thought a bit about sending mumsgs between muprocs not running in the
 > same Lisp image.  Arthur Lemmens has, in the context of rucksack,
 > developed a serialization protocol for arbitrary Lisp objects that could
 > be hijacked.  I talked briefly to him at the Lisp workshop of ecoop06;
 > he has no interest in factoring out that code himself, but thinks it
 > might be a viable method for sending Lisp objects between machines.

I neglected to reply to this part of Rudi's email of Friday: I looked at 
Arthur's code earlier this year, and as far as I can remember it should be 
relatively straightforward to use his serializer in muproc -- the code is very 
clean; I don't think it depends on too much other stuff (haven't checked 
though).  There is, however, quite a bit of other work that needs doing before 
muproc is distributed... ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3368 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mailman.common-lisp.net/pipermail/cl-muproc-devel/attachments/20060710/13957296/attachment.bin>

More information about the cl-muproc-devel mailing list