From: Jochen Schmidt
Subject: ANN: Portable AllegroServe 1.2.3a available (for LispWorks and CMUCL)
Date: 
Message-ID: <9kl6db$794$1@rznews2.rrze.uni-erlangen.de>
You can find it either in the CVS on

http://sourceforge.net/projects/portableaserve/

You can download a tarball with the actual release at
http://www.dataheaven.de

Regards,
Jochen Schmidt
 
--
http://www.dataheaven.de

From: Andrew K. Wolven
Subject: Re: ANN: Portable AllegroServe 1.2.3a available (for LispWorks and  CMUCL)
Date: 
Message-ID: <3B7002C8.38C8C72C@redfernlane.org>
Jochen Schmidt wrote:

> You can find it either in the CVS on
>
> http://sourceforge.net/projects/portableaserve/
>
> You can download a tarball with the actual release at
> http://www.dataheaven.de

Thanks for your work in this area.

So I gather from reading this web page that your CMUCL port is a
single-threaded port?
Do you happen to know how it might perform on CMUCL x86 linux with
preliminary thread support?

AKW


>
>
> Regards,
> Jochen Schmidt
>
> --
> http://www.dataheaven.de
From: Jochen Schmidt
Subject: Re: ANN: Portable AllegroServe 1.2.3a available (for LispWorks and   CMUCL)
Date: 
Message-ID: <9kp0s3$anf$1@rznews2.rrze.uni-erlangen.de>
Andrew K. Wolven wrote:

> 
> 
> Jochen Schmidt wrote:
> 
>> You can find it either in the CVS on
>>
>> http://sourceforge.net/projects/portableaserve/
>>
>> You can download a tarball with the actual release at
>> http://www.dataheaven.de
> 
> Thanks for your work in this area.
> 
> So I gather from reading this web page that your CMUCL port is a
> single-threaded port?
> Do you happen to know how it might perform on CMUCL x86 linux with
> preliminary thread support?

No it uses the stack-group based threadsupport of CMUCL on x86.
Maybe it would be a good idea to add a serve events version too...

Another possibility is the use of forks and therefore real UNIX-Processes.
AllegroServe supports this under AllegroCL/UNIX but it is untested under 
LispWorks and CMUCL. The functionality is in and all needed 
foreign-functions (like fork() ) are defined but as I said this is 
untested...
I will give it a try and will send you a message if this works.


ciao,
Jochen

--
http://www.dataheaven.de
From: Bulent Murtezaoglu
Subject: Re: ANN: Portable AllegroServe 1.2.3a available (for LispWorks and   CMUCL)
Date: 
Message-ID: <87y9ovyj5y.fsf@nkapi.internal>
>>>>> "JS" == Jochen Schmidt <ยทยทยท@dataheaven.de> writes:
[...]
    JS> Another possibility is the use of forks and therefore real
    JS> UNIX-Processes.  AllegroServe supports this under
    JS> AllegroCL/UNIX but it is untested under LispWorks and
    JS> CMUCL. The functionality is in and all needed
    JS> foreign-functions (like fork() ) are defined but as I said
    JS> this is untested...  

Not completely on topic, but this got me thinking about whether one
should invoke the GC before calling fork.  I am thinking of the case
where lots of short-life objects are created by a program before forking
several more processes.  This doesn't hurt anything initially because of 
copy-on-write, but the subsequent GC becomes expensive for all the 
processes and needlessly so IMHO.  Just an intuition, but I'd be 
interested to hear what others' experiences are.

cheers,

BM