[Openmcl-devel] Is there an updated aserve?

[Gary Byers]

On Mon, 22 Sep 2003, Eric Dahlman wrote:

>
> On Sunday, September 21, 2003, at 11:59 PM, Rudi Schlatte wrote:
>
> > On Montag, September 22, 2003, at 05:35  Uhr, Eric Dahlman wrote:
> >
> >> I grabbed the most recent build and tried to fire up aserve and found
> >> out that it won't run because of the changes to the mp code to remove
> >> run reasons and the like.  Now I agree with the rational for doing
> >> this but is there some sort of compatibility layer or a new version
> >> of portable allegro serve which I could use to get around this >> change?
> >>
> >
> > I hadn't yet tested paserve with recent versions of openmcl (I'm still
> > on 0.13 here).  Run reasons could be implemented with a global data
> > structure and some inter-thread singalling, similar in spirit to what
> > is done in the sbcl port.
> > Noted the problem, but I can't promise a date when it will be fixed
> > ("we take patches").  It's on my todo list, though.
>
> Sorry to sound like a whiney user :-)  I had looked at the scl and sbcl
> versions and even tried a first pass at naive cut and paste for support
> but then realized that it would take a bit more "figurin' out how stuff
> works" than I have time for.  This is on my "todo when I get a chance"
> list so you may get some patches from me, although the way things look
> that might be during the next interglacial warming period.
>
> Thanks a bunch!
>
> -Eric
>

Sorry for not replying earlier; I have really funky net access at the moment.

There's a version of paserve modified to work with OpenMCL's native
threads in the testing directory on clozure.com.  (That's
<ftp://clozure.com/pub/testing>, though there are ways to get there
via HTTP as well.)

That's the good news; the bad news is that it's based on a year-old version
of paserve and a several-months-old version of OpenMCL.  It may require some
tweaking on both fronts to work with the latest versions of both.

The general idea was to replace paserve's use of run-reasons with a queue
and a semaphore or two.  I was interested in this because it seemed like
a good way to stress-test native threads and seemed like a good example
of how a program that used the (quasi-lispm) cooperative threads API could
be changed to better exploit native threads.

I have at various times promised to update the paserve "example", but it's
always slipped through the cracks.  I'm on vacation until the end of the
week, but will try to work on this when I get back.  Honest.

Gary Byers
gb at clozure.com


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel