[cl-muproc-devel] [Patch] openmcl support

[Klaus Harbo]

Rudi Schlatte wrote:
> 
> On 5. Jul 2006, at 10:28, Klaus Harbo wrote:
> 
>> This is excellent!  I will try to integrate your patch later this week
>> and report back.  I'm curious as to your porting experience?  Was it
>> hard?  Is there anything I/we could learn from the exercise?  I hope
>> that we'll be able to add support for the most popular implementations,
>> so any porting insights are welcome!
> 
> Well, the only real hurdle was removing without-scheduling in 
> muproc-spawn, the rest was straightforward.  The port was basically 
> finished over a month ago, but I found the fencepost error in 
> consume-input only on tuesday.  I think the next ports will happen 
> faster now that we know that indeed only muproc-compat functionality is 
> needed to get cl-muproc running.
> 
> Cheers,
> 
> Rudi
> 

Hi Rudi --

I just installed your patch.  It looks very good indeed:  Everything 
seems to works as intended -- the tests all pass and the system we're 
building also seems to be doing just fine.  Excellent!

I have reviewed all your changes, and have only a single comment:  You 
introduce *muproc-spawn-lock* to serialize access to muproc-spawn.  I 
think perhaps it would be preferable to simply use 
%with-exclusive-access%.  In fact, thinking about this it occurred to me 
that (the previously existing) *giant-lock* probably be ought to be 
placed in the implementation specific files 
(muproc-{lispworks,openmcl}.lisp) because, strictly speaking, it is an 
artifact of the implementation of %with-exclusive-access% and not part 
of the implementation independent part of muproc.

So I propose that the new serialized muproc-spawn uses the generic 
%with-exclusive-access%, that *giant-lock* is moved to both 
implementation-specific files, and that *muproc-spawn-lock* is eliminated.

Let me know what you (which is plural 'you' btw, feel free to jump all 
you lurkers!) think...

Nice work, Rudi!

-Klaus.

PS.  In case anyone is wondering: I have not released a new version yet. 
  I will post a notice when that happens.
-------------- 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/20060706/6aa4d9d0/attachment.bin>