From: Dmitri H. <yav...@ya...> - 2005-11-03 15:17:10
|
Guten Tag! (this message was also posted to Clorb author) I use Clorb in my dictionary server, and on my iMac (MacOS X 10.3.9) Clorb versions 0.4-0.6 work with OpenMCL, SBCL and Clisp 2.33.2. However, they do not work with Clisp 2.35. It seems to me the problem is with EXT:SOCKET-STATUS and friends like EXT:READ-BYTE-WILL-HANG-P or EXT:READ-BYTE-LOOKAHEAD. Synopsis: 1. with the Clorb code unchanged at all, call (hello-client :file "/tmp/hello.ior") never finishes. First portion of server answer is read, GET-RESPONSE-0 is called, GET-RESPONSE-REPLY is installed as connection read callback, but it gets never called, instead EXT:SOCKET-STATUS returns NIL at 60 sec. intervals. 2. with the following kludge in ORB-WORK (see #+clisp line) (defun orb-work (orb run-queue poll) (when run-queue (orb-run-queue orb)) (let ((event-processed nil)) (loop for event = (io-get-event) while event do (setq event-processed t) (let* ((desc (second event)) (conn (io-descriptor-connection desc))) (mess 1 "io-event: ~S ~A ~A" (car event) (io-descriptor-stream desc) conn) (case (car event) (:read-ready (when conn (connection-read-ready conn)) #+clisp(unless (ext:read-byte-will-hang-p (io-descriptor-stream desc)) (io-poll-desc desc :input))) (:write-ready ;; the rest of orb-work GET-RESPONSE-REPLY is called and server answer is correctly parsed, but the top-level call still doesn't return, as it blocks in EXT:READ-BYTE-WILL-HANG-P 3. with the following awful kludge (see "hrap" lines) (defun orb-work (orb run-queue poll) (when run-queue (orb-run-queue orb)) (let ((event-processed nil) (hrap t) ;hrap ) (loop for event = (io-get-event) while event do (setq event-processed t) (let* ((desc (second event)) (conn (io-descriptor-connection desc))) (mess 1 "io-event: ~S ~A ~A" (car event) (io-descriptor-stream desc) conn) (case (car event) (:read-ready (when conn (connection-read-ready conn)) (when hrap (setf hrap nil) (io-poll-desc desc :input)) ;hrap ) (:write-ready ;; the rest of orb-work CORBA call at last succeeds (returns "Hello World from OpenMCL"), but of course it won't work when server's anwer arrives in multiple pieces. Additional notes: 1. with CVS version of Clisp I wasn't able to even send request to server. 2. Clorb + Clisp 2.35 didn't work for me on FreeBSD either, if I remember correctly 3. IMHO now it's possible to remove many conditionals from Clorb as Clisp support MOP; I'll try to do it after this issue is resolved Thanks for your help, Dmitri |
From: Sam S. <sd...@gn...> - 2005-11-03 15:39:59
|
> * Dmitri Hrapof <lninaanqvy@lnubb.pbz> [2005-11-03 14:52:37 +0000]: > > I use Clorb in my dictionary server, and on my iMac (MacOS X 10.3.9) > Clorb versions 0.4-0.6 work with OpenMCL, SBCL and Clisp 2.33.2. > However, they do not work with Clisp 2.35. > It seems to me the problem is with EXT:SOCKET-STATUS and friends > like EXT:READ-BYTE-WILL-HANG-P or EXT:READ-BYTE-LOOKAHEAD. I do not use clorb, but if you could isolate the problem and produce a stand-alone test case (preferable working with 2.33.2 but not with the CVS head), I would look at it. > 1. with CVS version of Clisp I wasn't able to even send request to > server. same here - an isolated test case that does not require me to download and install clorb would be nice. > 2. Clorb + Clisp 2.35 didn't work for me on FreeBSD either, if I > remember correctly both 2.35 and cvs head work on FreeBSD, so, again, I need a test case. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.memri.org/> <http://ffii.org/> <http://www.iris.org.il> <http://truepeace.org> <http://www.dhimmi.com/> A slave dreams not of Freedom, but of owning his own slaves. |
From: Dmitri H. <yav...@ya...> - 2005-11-03 17:24:15
|
Sam Steingold <sds <at> gnu.org> writes: > I do not use clorb, but if you could isolate the problem and produce a > stand-alone test case (preferable working with 2.33.2 but not with the > CVS head), I would look at it. It's a fair request; I have to admit I can't produce such a case yet; this one works :-) (defun bug-server (port) (let ((stream (socket-accept (socket-server port) :element-type '(unsigned-byte 8))) (seq (make-array 53 :element-type '(unsigned-byte 8)))) (socket-status stream) (read-byte-sequence seq stream :start 0 :end 53 :no-hang t) (dotimes (i 53) (setf (aref seq i) i)) (write-sequence seq stream) (force-output stream) (read))) (defun bug-client (port) (let ((stream (socket-connect port "localhost" :element-type '(unsigned-byte 8))) (seq (make-array 53 :element-type '(unsigned-byte 8)))) (write-sequence seq stream) (force-output stream) (socket-status (list stream) 60) (read-byte-sequence seq stream :start 0 :end 12 :no-hang t) (format t "~A~%" seq) (socket-status (list stream) 60) (read-byte-sequence seq stream :start 12 :end 53 :no-hang t) (format t "~A~%" seq))) |
From: Sam S. <sd...@gn...> - 2005-11-03 17:39:59
|
> * Dmitri Hrapof <lninaanqvy@lnubb.pbz> [2005-11-03 17:14:09 +0000]: > > Sam Steingold <sds <at> gnu.org> writes: > >> I do not use clorb, but if you could isolate the problem and produce a >> stand-alone test case (preferable working with 2.33.2 but not with the >> CVS head), I would look at it. > > It's a fair request; thank you. > I have to admit I can't produce such a case yet; note that the socket stream performance and behavior can be drastically affected by the stream buffering. <http://clisp.cons.org/impnotes/stream-dict.html#buffered>. note also that socket-status et al are tricky when buffering is involed, (and a bug there has been fixed in the CVS recently). -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.palestinefacts.org/> <http://www.memri.org/> <http://pmw.org.il/> <http://truepeace.org> <http://www.camera.org> <http://www.jihadwatch.org/> Good judgment comes from experience and experience comes from bad judgment. |
From: Dmitri H. <yav...@ya...> - 2005-11-07 05:37:42
|
Sam Steingold <sds <at> gnu.org> writes: > note that the socket stream performance and behavior can be drastically > affected by the stream buffering. > <http://clisp.cons.org/impnotes/stream-dict.html#buffered>. > note also that socket-status et al are tricky when buffering is involed, > (and a bug there has been fixed in the CVS recently). Indeed! To quote CLORB's author Lennart Staflin: "I think the problem is that the socket stream is buffered and socket-status doesn't report on what's already in the buffer. CLORB reads a IIOP message in two steps, first the header to get the length of the message and then the rest. Probably the stream will automatically read everything that is available and buffer it for the first read. Then socket-status won't report there is anything to read, although EXT:READ-BYTE-LOOKAHEAD will. There is a similar problem with CMUCL. I have a workaround for that because I couldn't figure out how to turn off buffering. For CLISP it seems simple to turn the buffering off when the connection is created. That seems to fix it for me." IMHO it's not the most obvious semantics for SOCKET-STATUS, is it? However, now things work. |
From: Sam S. <sd...@gn...> - 2005-11-07 14:15:02
|
> * Dmitri Hrapof <lninaanqvy@lnubb.pbz> [2005-11-07 05:35:44 +0000]: > > Sam Steingold <sds <at> gnu.org> writes: > >> note that the socket stream performance and behavior can be drastically >> affected by the stream buffering. >> <http://clisp.cons.org/impnotes/stream-dict.html#buffered>. >> note also that socket-status et al are tricky when buffering is involed, >> (and a bug there has been fixed in the CVS recently). > > Indeed! To quote CLORB's author Lennart Staflin: > > "I think the problem is that the socket stream is buffered and > socket-status doesn't report on what's already in the buffer. CLORB > reads a IIOP message in two steps, first the header to get the length > of the message and then the rest. Probably the stream will > automatically read everything that is available and buffer it for the > first read. Then socket-status won't report there is anything to read, > although EXT:READ-BYTE-LOOKAHEAD will. There is a similar problem with > CMUCL. I have a workaround for that because I couldn't figure out how > to turn off buffering. For CLISP it seems simple to turn the buffering > off when the connection is created. That seems to fix it for me." > > IMHO it's not the most obvious semantics for SOCKET-STATUS, is it? > > However, now things work. the handling of buffered streams by SOCKET-STATUS has been fixed in the CVS head. it would be nice if you could test it. thanks. -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.mideasttruth.com/ http://ffii.org/ http://www.savegushkatif.org http://www.palestinefacts.org/ http://www.openvotingconsortium.org/ Lisp is a way of life. C is a way of death. |
From: Dmitri H. <yav...@ya...> - 2005-11-12 11:25:14
|
Sam Steingold <sds <at> gnu.org> writes: > the handling of buffered streams by SOCKET-STATUS has been fixed in the > CVS head. > it would be nice if you could test it. I've tried to build clisp from CVS, but failed with various errors. Guess it's time for me to upgrade MacOS to 10.4 and gcc (3.1 20020420) :-( |
From: Devon S. M. <Lisp-Hacker@Jovi.Net> - 2005-11-12 14:14:20
|
From: Dmitri Hrapof <yav...@ya...> Date: Sat, 12 Nov 2005 11:22:10 +0000 (UTC) Sam Steingold <sds <at> gnu.org> writes: > the handling of buffered streams by SOCKET-STATUS has been fixed in the > CVS head. > it would be nice if you could test it. I've tried to build clisp from CVS, but failed with various errors. Guess it's time for me to upgrade MacOS to 10.4 and gcc (3.1 20020420) :-( You'll get the same errors. If we could see the header files and build-generated sources that went into builds on other systems, that might nail the errors. Pointers, anyone? Peace --Devon /~\ \ / Health Care X not warfare / \ Dubya won the digital vote Kerry won the popular vote |
From: Sam S. <sd...@gn...> - 2005-11-12 23:54:51
|
> * Devon Sean McCullough <Yvfc-Unpxre@Wbiv.Arg> [2005-11-12 09:13:53 -0500]: > > From: Dmitri Hrapof <yav...@ya...> > Date: Sat, 12 Nov 2005 11:22:10 +0000 (UTC) > > Sam Steingold <sds <at> gnu.org> writes: > > > the handling of buffered streams by SOCKET-STATUS has been fixed in the > > CVS head. > > it would be nice if you could test it. > > I've tried to build clisp from CVS, but failed with various errors. > Guess it's time for me to upgrade MacOS to 10.4 and gcc (3.1 20020420) > :-( > > You'll get the same errors. If we could see the header files > and build-generated sources that went into builds on other > systems, that might nail the errors. Pointers, anyone? clisp cvs head builds ootb on sf cf ppc-osx2 if you are experiencing problems, please see clisp faq and search for "bugs" -- Sam Steingold (http://www.podval.org/~sds) running w2k http://www.openvotingconsortium.org/ http://truepeace.org http://www.palestinefacts.org/ http://www.savegushkatif.org Lisp: its not just for geniuses anymore. |