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

Klaus Harbo klaus at mu.dk
Mon May 29 21:01:41 UTC 2006


Rudi Schlatte wrote:
>
> On 29. Mai 2006, at 11:07, Klaus Harbo wrote:
>
>> 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.
>
> FWIW, I now think it's better to truncate muproc-compat so that it 
> does not define the "stub" compat functions/macros.  At least some 
> warnings might be due to that.

Yes, they are.  It's a dilemma, though, to my mind.  I definitely want 
to get rid of the warnings, and removing the stub functions would do 
that.  But on the other hand it is attractive to have a clear statement 
of the compat-functions required to make a full implementation.  If we 
lose the stub functions, we'll lose that.

Could changing

  :components
  ((:file "muproc-packages")
   (:file "muproc-compat" :depends-on ("muproc-packages"))
   #+lispworks (:file "muproc-lispworks" :depends-on ("muproc-compat"))
   (:file "muproc" :depends-on ("muproc-compat"
                                #+lispworks "muproc-lispworks"))
   (:file "generic-server" :depends-on ("muproc"))
   (:file "supervisor" :depends-on ("muproc"))
   ))

in cl-muproc.asd to something along the lines of

  :components
  ((:file "muproc-packages")
   #-(or lispworks other-impl) (:file "muproc-compat" :depends-on 
("muproc-packages"))
   #+lispworks (:file "muproc-lispworks" :depends-on ("muproc-packages"))
   #+other-impl (:file "muproc-other-impl" :depends-on ("muproc-packages"))
   (:file "muproc" :depends-on (#-(or lispworks other-impl) "muproc-compat"
                                #+lispworks "muproc-lispworks"
                                #+other-impl "muproc-other-impl"))
   (:file "generic-server" :depends-on ("muproc"))
   (:file "supervisor" :depends-on ("muproc"))
   ))

perhaps balance these requirements?  Perhaps someone can point to a 
model from other projects that we can use/borrow/steal?
>
> Another thing that doesn't warrant its own mail yet: I got most of the 
> openmcl port done.  What's missing is a stable version of 
> muproc-spawn.  It might be necessary to introduce another function in 
> cl-muproc.comat, something like create-and-init-thread (thread-fn 
> init-fn) that does the things muproc-spawn does inside the 
> %without-scheduling% form.  Lisp platforms that use native threads 
> can't support without-scheduling, but at least in openmcl it is 
> possible to create a thread structure without starting it, so 
> cl-muproc.compat:create-and-init-thread will use without-scheduling on 
> lispworks and create-thread->(funcall init-fn)->start-thread on 
> openmcl.  I'll send a patch once the basic muproc tests are running.
>
> Cheers,
>
> Rudi
>
See my previous posting.

-Klaus.




More information about the cl-muproc-devel mailing list