[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