Hi all,
what is the status of latest ECL support in usocket?
By running tests it seems that some stuff is not supported yet. I'm trying to get hunchentoot to run with ECL, managed to make it compile hunchentoot with some patches, but when running it fails in usocket:wait-for-input-internal.
If someone is interested to give it a try, I can send WIP hunchentoot patch.
Regards, Marko Kocić
Hi, Marko
What's your platform? If it's not MS Windows, please show your backtraces when error happens.
Regards,
Chun Tian (binghe)
在 2010-2-12，01:24， Marko Kocić 写道：
Hi all,
what is the status of latest ECL support in usocket?
By running tests it seems that some stuff is not supported yet. I'm trying to get hunchentoot to run with ECL, managed to make it compile hunchentoot with some patches, but when running it fails in usocket:wait-for-input-internal.
If someone is interested to give it a try, I can send WIP hunchentoot patch.
Regards, Marko Kocić
usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Hi Chun Tian,
The platform is Ubuntu 9.04 x64. Here's the patch to hunchentoot to make it compile with ecl. When I try to run hunchentoot tests or to access any page I get different errors.
I don't know when to start looking, since I'm new to both usockets and hunchentoot.
Regads, Marko
On Fri, Feb 12, 2010 at 1:18 AM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, Marko
What's your platform? If it's not MS Windows, please show your backtraces when error happens.
Regards,
Chun Tian (binghe)
在 2010-2-12，01:24， Marko Kocić 写道：
Hi all,
what is the status of latest ECL support in usocket?
By running tests it seems that some stuff is not supported yet. I'm trying to get hunchentoot to run with ECL, managed to make it compile hunchentoot with some patches, but when running it fails in usocket:wait-for-input-internal.
If someone is interested to give it a try, I can send WIP hunchentoot patch.
Regards, Marko Kocić
usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
Hi, Marko
I used latest USOCKET code on trunk and Hunchentoot 1.1.0 with your patch. Every files compiled fined and I can start hunchentoot test server. But when I tried to connect to it using a web browser, I got this error:
(hunchentoot:start (make-instance 'hunchentoot:acceptor :port 4242))
#<HUNCHENTOOT:ACCEPTOR (host *, port 4242)>
Detected access to an invalid or protected memory address.
No restarts available.
Broken at NIL. In: #<process "Hunchentoot worker (client: 127.0.0.1:6153)" 0000000104f0d840>.
I think you may got the same behavior as me. The problem is, I need to look into the backtrace in the thread #<process "Hunchentoot worker (client: 127.0.0.1:6153)" 0000000104f0d840>, but I don't know to "switch" to that thread in ECL listener ...
--binghe
在 2010-2-12，23:32， Marko Kocić 写道：
Hi Chun Tian,
The platform is Ubuntu 9.04 x64. Here's the patch to hunchentoot to make it compile with ecl. When I try to run hunchentoot tests or to access any page I get different errors.
I don't know when to start looking, since I'm new to both usockets and hunchentoot.
Regads, Marko
On Fri, Feb 12, 2010 at 1:18 AM, Chun Tian (binghe) binghe.lisp@gmail.com wrote:
Hi, Marko
What's your platform? If it's not MS Windows, please show your backtraces when error happens.
Regards,
Chun Tian (binghe)
在 2010-2-12，01:24， Marko Kocić 写道：
Hi all,
what is the status of latest ECL support in usocket?
By running tests it seems that some stuff is not supported yet. I'm trying to get hunchentoot to run with ECL, managed to make it compile hunchentoot with some patches, but when running it fails in usocket:wait-for-input-internal.
If someone is interested to give it a try, I can send WIP hunchentoot patch.
Regards, Marko Kocić
usocket-devel mailing list usocket-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel
<hunchentoot-ecl.patch>
Yes, the problem was similar.
After updating ECL from git, it seems it behaves differently now. When I try hunchentoot test it just waits and does nothing.
Regards, Marko
CC-ing ecl-list since this might look similar to problems that ecl git currenty have with new slime.
You can see backtrace by attaching gdb to ecl process. You do something like: pgrep ecl gdb ~/bin/ecl ecl_pid
Right now I'm getting this backtrace while running hunchentoot-tests.
(gdb) bt #0 0x00007f8c73f05a6b in read () from /lib/libc.so.6 #1 0x00007f8c73ea5ad8 in _IO_file_underflow () from /lib/libc.so.6 #2 0x00007f8c73ea54a8 in ?? () from /lib/libc.so.6 #3 0x00007f8c73e9b312 in fread () from /lib/libc.so.6 #4 0x00007f8c74968f9b in fread (strm=0x5192e60, c=0x7fffb2b958ef "", n=1) at /usr/include/bits/stdio2.h:287 #5 input_stream_read_byte8 (strm=0x5192e60, c=0x7fffb2b958ef "", n=1) at /home/markko/cvstree/ecl.git/src/c/file.d:3215 #6 0x00007f8c74968805 in generic_read_byte_unsigned8 (strm=0x4) at /home/markko/cvstree/ecl.git/src/c/file.d:321 #7 0x00007f8c74971f13 in cl_read_byte (narg=3, binary_input_stream=0x5192d20) at /home/markko/cvstree/ecl.git/src/c/read.d:1838 #8 0x00007f8c6987efdd in LC12stream_read_byte (V1=0x6b405d0) at /home/markko/.fasls/ecl-10.2.1-linux-x86-64/home/markko/.cache/common-lisp/ecl-10.2.1-linux-x86-64/home/markko/cvstree/clbuild/source/chunga/input.c:338 #9 0x00007f8c7495ac3f in cl_apply (narg=2, fun=0x47fd7c0, lastarg=0x7fffb2b95d40) at /home/markko/cvstree/ecl.git/src/c/eval.d:138 #10 0x00007f8c7490c0dd in LC2__g4 (narg=<value optimized out>, V1=<value optimized out>, V2=0x6c093d1) at /home/markko/cvstree/ecl.git/build/clos/combin.c:117 #11 0x00007f8c7490bf37 in LC4__g5 (narg=<value optimized out>, V1=0x7fffb2b95d40, V2=<value optimized out>) at /home/markko/cvstree/ecl.git/build/clos/combin.c:149
On Tue, Feb 16, 2010 at 10:53 AM, Marko Kocić marko.kocic@gmail.com wrote:
Yes, the problem was similar.
After updating ECL from git, it seems it behaves differently now. When I try hunchentoot test it just waits and does nothing.
Regards, Marko
On Tue, Feb 16, 2010 at 6:10 PM, Marko Kocić marko.kocic@gmail.com wrote:
CC-ing ecl-list since this might look similar to problems that ecl git currenty have with new slime.
It does not seem that similar: here the error does not result in a stack overflow.
Regardung usocket, let me comment on a change that happened recently in ECL. The port of Slime to ECL uses the SB-SOCKETs package. So far so good. The problem is that Slime (or Swank) sets up threads that concurrently read and write to the socket stream. More precisely, one thread may be listening 100% of the time while others write to the same communication channel.
That should be fine, but the problem is that ANSI C streams may lock and ECL is using internally those streams for implementing buffered sockets. More precisely, ECL used an I/O FILE stream for the same socket. This results in Slime being locked due to the listening thread, that prevents all communication from ECL back to Emacs.
The solution we (actually Ram) came up with is to associate a two-way stream to the socket. This is now the stream that is built by socket-make-stream and which is stored in the appropriate slots of the socket class. This seemingly insignificant change is not: there are many operations that can not be performed on two-way streams, such as seek or close.
So, I am just wondering whether usocket uses the socket streams in a way that the latest change may cause troubles.
Just talking out of ignorance, since I do not use usocket myself.
Juanjo
-
Chun Tian (binghe) -
Juan Jose Garcia-Ripoll -
Marko Kocić