[cl-muproc-devel] Integration of OpenMCL and SBCL/CMUCL patches in darcs repo -- testing requested
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...
Size: 3368 bytes
Desc: S/MIME Cryptographic Signature
More information about the cl-muproc-devel