[cl-muproc-devel] [Patch] Reorganisation of impl-dependent functions: proposal

[Klaus Harbo]

Rudi Schlatte wrote:
> Hello all,
> 
> Thanks to the good work of Klaus, cl-muproc already has a good 
> separation of core functions and implementation-dependent code.  There 
> is no explicit dependence on lispworks anywhere except 
> muproc-compat.lisp[1], so porting to other implementations should be 
> easy.  In order to keep things tidy, I propose to gather each 
> implementation's code into its own file.  The attached patch implements 
> this for lispworks.
> 
> The patch also removes the dependency upon acl-compat.  The rationale is 
> two-fold:
> - some implementation-dependent code is necessary anyway, because 
> acl-compat does not implement lispworks-style mailboxes (nor 
> condition-variables, upon which mailboxes can be built).
> - acl-compat pulls in cl-ppcre and puri, two libraries that are 
> completely unrelated to multiprocessing.
> 
> With this patch, starting a new port would consist of:
> - copying muproc-compat.lisp to muproc-<implementation>.lisp
> - adding the file to cl-muproc.asd
> - implementing the stub functions in muproc-<implementation>.lisp
> 
> I feel this is a better solution than adding to an ever-expanding 
> muproc-compat.lisp.
> 
> Cheers,
> 
> Rudi
> 
> 
> [1] The implicit dependence is without-scheduling, which presupposes the 
> scheduler is under control of the Lisp runtime.  The last time I looked 
> at that part of the code in depth (on the train ride back from Hamburg), 
> I felt confident that the code without-scheduling could be rewritten 
> without it.

Rudi --

Thanks for the patch!  Sorry for being so slow in responding -- I have 
been effectively offline for a few days!  I have taken a brief look at 
your patch and overall I think your proposal looks very sensible.  I 
think I agree with getting rid of the dependency on acl-compat, since it 
is so small anyway.  Your patch does cause a number of warnings in LW 
that I'd prefer to get rid of, so I'll take a better look at the code, 
probably later today (read: tonight).  More later.

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/20060529/14bfa6e7/attachment.bin>