[cl-muproc-devel] Re: Bordeaux-Threads usage

[Klaus Harbo]

Greg Pfeil wrote:
> Hey, I was about to start using CL-MUPROC, and happily noticed that it's 
> using the Bordeaux-Threads library I wrote. However, it only seems to be 
> using it for SBCL and CMUCL. My aim is for it to be an extremely 
> portable threading layer, so I'm interested in knowing what problems you 
> may have had with it on on other platforms and any other functionality 
> you feel would be necessary in such a library (EG, I see you use 
> PROCESS-ALIVE-P, which Bordeaux-Threads doesn't currently supply).
> 
> Also, if there are any general suggestions about the library, I'd also 
> be happy to hear those.
> 
> In any case, I'm excited to start using CL-MUPROC. Thanks.
> 

Hi Greg --

I sorry for taking so long to respond -- I'm afraid Thunderbird deemed your mail 
to be Spam so I didn't see until I was cleaning out folders this morning!

cl-muproc started out on Allegro (while we were evaluating that product), then 
moved to Lispworks.  My focus from the start was squarely on functionality, so I 
paid no attention to implementation independence at all.  When cl-muproc was 
open sourced, I realized that I could help adoption by making porting easier, so 
I decided simply to isolate all LW-specific code in a separate layer.  That way 
it would be clear for potential porters what was needed to make a port.

I believe it was Vladimir Sekissov who introduced bordeaux-threads while working 
on the the SBCL/CMUCL port.  Overall, I feel that cl-muproc portability model is 
  fine as it is, that is that there is a clear separation between platform 
INdependent and dependent code.  If you look at the code, you'll see that the 
layer isolating the two is really simple, which is good.  I'm glad that 
bordeaux-threads exists -- it makes porting like this much easier -- and 
wouldn't mind that more ports relied on it.  However, I also think it is a good 
idea for cl-muproc to have its own isolation layer, so that a port does not have 
to use bordeaux-threads.

Wrt. process-alive-p it is used by the supervisor in cl-muproc, which absolutely 
needs to be able to detect if a process has terminated.  Reading 
muproc-sbcl.lisp and muproc-cmucl.lisp it seems clear that the porting effort of 
this particular call was not too great, even if it was not part of 
bordeaux-threads... ;-)   However, if your ambition for bordeaux-threads is that 
it be possible to use the same bordeaux-based MP code on many implementations, 
then you should perhaps consider adding calls like process-alive-p.  cl-muproc's 
supervisor certainly needs it.

Thanks for writing, good luck with cl-muproc!  Any feed-back wrt. your 
experiences using muproc, good or bad, would be appreciated...

best regards,

-Klaus.
-------------- 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/20061011/06dd746e/attachment.bin>