What is the current status on Portable Allegroserve?
I tried to load release 1.2.12c under CMUCL 18d(1). I loads fine, but
when I try to run the example I get:
* (start-server :port 2001)
#<Process aserve-example {4845CE85}>
*
#<Stream for Standard Input> is not a binary input stream.
Restarts:
0: [ABANDON] Abandon this request and wait for the next one
1: [DESTROY] Destroy the process
Debug (type H for help)
(COMMON-LISP::ILL-BIN #<Stream for Standard Input>)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists:
target:code/stream.lisp.
0]
What release of CMUCL is used for the qualification of Portable
Allegroserve?
1) http://www.caddr.com/lisp/cmucl-18d-1.i386.rpm
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
Petter Gustad <·············@gustad.com> writes:
> What is the current status on Portable Allegroserve?
>
> I tried to load release 1.2.12c under CMUCL 18d(1). I loads fine, but
> when I try to run the example I get:
The latest CVS release of Portable Allegroserve seems to work fine
under CMUCL 18d.
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | ~8'h2B http://www.gustad.com/petter
Petter Gustad <·············@gustad.com> writes:
> Petter Gustad <·············@gustad.com> writes:
>
> > What is the current status on Portable Allegroserve?
> >
> > I tried to load release 1.2.12c under CMUCL 18d(1). I loads fine, but
> > when I try to run the example I get:
>
> The latest CVS release of Portable Allegroserve seems to work fine
> under CMUCL 18d.
>
Yes, and my reply to Petter was meant to be posted to the group anyway,
but my fingers slipped :-/
In a nutshell:
- There hasn't been a release for too long
- CVS works better than the last released version (for cmucl)
- Main testing is done on Debian (testing/unstable) cmucl
- The problem described in Petter's post occurred because bivalent
streams are only implemented in the CVS version
- We'd like to hear if there are any problems loading/installing
paserve, even if you suspect it's PEBKAC; loading
portableaserve/INSTALL.lisp should Just Work (tm). For added
privacy, you can also report to the project mailing lists and/or by
private mail
Thanks to Petter for following up on his own.
Regards,
Rudi
Rudi Schlatte <····@constantly.at> wrote:
> - We'd like to hear if there are any problems loading/installing
> paserve, even if you suspect it's PEBKAC; loading
> portableaserve/INSTALL.lisp should Just Work (tm). For added
> privacy, you can also report to the project mailing lists and/or by
> private mail
Well, I've got a question.
I'm using the Nov. 4 2002 cmucl (linux, downloaded binaries) and
portableaserve version 1.2.12c. While trying to load code which
worked (with the exception of strange forgotten file descriptors)
under cmucl-18c and paserve 1.2.5a, I got some new messages:
1-aserve-worker: 11/21/02 - 16:14:25 - got error Type-error in
KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
NIL is not of type STREAM
2-aserve-worker: 11/21/02 - 16:14:25 - got error Type-error in
KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
NIL is not of type STREAM
(through 5-aserve-worker)
After that, it repeats this forever after:
aserve-accept-6: 11/21/02 - 16:14:25 - accept: error 0 on accept No
matching method for the generic-function #<Standard-Generic-Function
ACL-SOCKET:ACCEPT-CONNECTION (1)
{48998FD9}>, when called with
arguments (NIL).
I have no idea where to even begin looking for this. Has anyone else
had this experience?
thanks,
Michael
I don't know if it's useful, but here's a backtrace. It's definitely
the web listener; destroying this process allows the rest to go on,
even making outgoing connections, but I can't talk to the web server
then.
0] backtrace
0: (DEBUG::DEBUG-LOOP)
1: (DEBUG:INTERNAL-DEBUG)
2: (DEBUG::INVOKE-TTY-DEBUGGER #<SIMPLE-CONDITION {48DF458D}>)
3: (DEBUG::REAL-INVOKE-DEBUGGER #<SIMPLE-CONDITION {48DF458D}>)
4: (INVOKE-DEBUGGER #<SIMPLE-CONDITION {48DF458D}>)
5: (BREAK "Interrupted at #x~x." 134577537)
6: (UNIX::SIGINT-HANDLER #<#1=unused-arg> #<#1#> #.(SYSTEM:INT-SAP
#x3FFFE628))
7: (UNIX::SIGINT-HANDLER 3
#<#1=unused-arg>
#<#1#>
#.(SYSTEM:INT-SAP #x3FFFE628))[:EXTERNAL]
8: ("Foreign function call land")
9: ("Foreign function call land")
10: ("Foreign function call land")
11: ("Foreign function call land")
12: ("Foreign function call land")
13: ("Foreign function call land")
14: ("Foreign function call land")
15: ("Foreign function call land")
16: (DEBUG-INTERNALS::COMPONENT-PTR-FROM-PC #.(SYSTEM:INT-SAP
#x10EFCD57))
17: (DEBUG-INTERNALS::COMPUTE-LRA-DATA-FROM-PC #.(SYSTEM:INT-SAP
#x10EFCD57))
18: (DEBUG-INTERNALS::COMPUTE-CALLING-FRAME #.(SYSTEM:INT-SAP
#x3FFFED30)
#.(SYSTEM:INT-SAP
#x10EFCD57)
#<Compiled-Frame CERROR>)
19: (DEBUG-INTERNALS:FRAME-DOWN #<Compiled-Frame CERROR>)
20: (KERNEL:FIND-CALLER-NAME)
21: (CERROR "Retry call to ~S"
NO-APPLICABLE-METHOD
:FUNCTION
#<Standard-Generic-Function ACL-SOCKET:ACCEPT-CONNECTION
(1)
{48411841}>
...)
22: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<#1=unused-arg> #<#1#>
#<Standard-Generic-Function ACL-SOCKET:ACCEPT-CONNECTION (1)
{48411841}>
(NIL))
23: (NET.ASERVE::HTTP-ACCEPT-THREAD)
24: (ACL-COMPAT-MP::APPLY-WITH-BINDINGS
#<Function NET.ASERVE::HTTP-ACCEPT-THREAD {48797E99}>
NIL
((NET.ASERVE:*WSERVER* QUOTE #)))
25: ("DEFUN RESTART-PROCESS")
From: Aleksandr Skobelev
Subject: Re: Portable Allegroserve and CMUCL
Date:
Message-ID: <m3adk2m1y8.fsf@list.ru>
I have no experience with PAServe, but it looks like it's failed to open socket
and gives NIL instead of a stream to ACL-SOCKET:ACCEPT-CONNECTION. Or it might
be that there is something wrong with bindings for NET.ACCEPT:*WSERVER* which
contains that socket.
····@pobox.com (Michael Hannemann) writes:
[...]
>
> aserve-accept-6: 11/21/02 - 16:14:25 - accept: error 0 on accept No
> matching method for the generic-function #<Standard-Generic-Function
> ACL-SOCKET:ACCEPT-CONNECTION (1)
> {48998FD9}>, when called with
> arguments (NIL).
>
> I have no idea where to even begin looking for this. Has anyone else
> had this experience?
>
>
> thanks,
>
> Michael
Aleksandr Skobelev <···········@list.ru> wrote:
> I have no experience with PAServe, but it looks like it's failed to open
> socket and gives NIL instead of a stream to ACL-SOCKET:ACCEPT-CONNECTION.
> Or it might be that there is something wrong with bindings for
> NET.ACCEPT:*WSERVER* which contains that socket.
Interestingly enough, I notice that it does it simply running the
example, with no code of my own in the way. I'm using that as a basis
to check into it more.
Michael
Looking into it, just loading mk-defsystem and paserve 1.2.12c and the
example, in the http-worker-thread function,
(let ((sock (car (acl-mp:process-run-reasons
acl-mp:*current-process*)))) ...)
binds sock to nil, which isn't checked for. There are no
process-run-reasons.
Now, in this case, half of it still works fine -- I can browse to the
port and run the example tests. But it doesn't quite seem like it's
behaving correctly, somehow.
Michael
(posting via google, so I can only see new messages slowly)
Michael Hannemann wrote:
> Looking into it, just loading mk-defsystem and paserve 1.2.12c and the
> example, in the http-worker-thread function,
> (let ((sock (car (acl-mp:process-run-reasons
> acl-mp:*current-process*)))) ...)
>
> binds sock to nil, which isn't checked for. There are no
> process-run-reasons.
Well - if (acl-mp:process-run-reasons acl-mp:*current-process*) returns NIL
then something really weird is going on. The current process would not be
allowed to run if he has no run-reasons. In this case this means that
acl-mp:process-run-reasons should block until there are run-reasons.
Therefore testing sock for NIL is not really needed if
acl-mp:process-run-reasons behaves the way it should.
ciao,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt wrote:
> Michael Hannemann wrote:
>
>> Looking into it, just loading mk-defsystem and paserve 1.2.12c and the
>> example, in the http-worker-thread function,
>> (let ((sock (car (acl-mp:process-run-reasons
>> acl-mp:*current-process*)))) ...)
>>
>> binds sock to nil, which isn't checked for. There are no
>> process-run-reasons.
>
> Well - if (acl-mp:process-run-reasons acl-mp:*current-process*) returns
> NIL then something really weird is going on. The current process would not
> be allowed to run if he has no run-reasons. In this case this means that
> acl-mp:process-run-reasons should block until there are run-reasons.
> Therefore testing sock for NIL is not really needed if
> acl-mp:process-run-reasons behaves the way it should.
I have looked into the code and it seems acl-mp:process-run-reasons does not
block b ut simply return the run-reasons of the process. The problem here
is maybe that the process is not disabled successfully on creation. PAServe
creates worker threads which have no run-reasons at the beginning and
therefore should not be runnable. I could imagine that under CMUCL the
worker threads are not disabled and therefore get NIL as socket for exactly
one round. At the end (acl-mp:process-revoke-run-reason
acl-mp:*current-process* sock) disables the worker successfully and it
should work from then on.
My idea for further investigation would be the implementation of
ACL-MP:PROCESS-PRESET. Maybe a call to (setf (process-run-reasons proc)
(process-run-reasons proc)) should be done in ACL-P:PROCESS-PRESET. This
would disable the process if there are no run-reasons.
ciao,
Jochen
--
http://www.dataheaven.de
····@pobox.com (Michael Hannemann) writes:
> I'm using the Nov. 4 2002 cmucl (linux, downloaded binaries) and
> portableaserve version 1.2.12c. While trying to load code which
> worked (with the exception of strange forgotten file descriptors)
> under cmucl-18c and paserve 1.2.5a, I got some new messages:
Can you observe the same behavior with CVS paserve? (see
<URL:http://sourceforge.net/cvs/?group_id=32760> for instructions on
how to get it.) Regrettably, 1.2.12c seems broken on newer cmucls;
as mentioned, the current code has been waiting in CVS for a release
for too long already.
Thanks,
Rudi
I've got a strange question for you. Is there a reason why, in
acl-socket-cmu.lisp, :auto-close T is only used for incoming
connections, and not active outgoing ones? The entire reason I'm
looking at new aserve/cmucl is that I've got a program which is
leaking sockets when it attempts to make outgoing connections to
machines which are down.
thanks,
Michael