From psilord at cs.wisc.edu Mon Feb 1 02:15:52 2010 From: psilord at cs.wisc.edu (Peter Keller) Date: Sun, 31 Jan 2010 20:15:52 -0600 Subject: [iolib-devel] fd handlers Message-ID: <20100201021552.GA466@cs.wisc.edu> Hello, Is there a means by which a handler registered with set-io-handler can be "deactivated" so that it isn't considered in the fd set being checked and "reactivated" later to be put back into the fd set? I ask because I might not have access to the function which I want associated, say with a write handler, but when the buffer the write handler is writing is empty. If the write handler is always activated on an empty buffer solely because it is in the write handler callback, then that is a performance problem. Thank you. -pete From sionescu at cddr.org Mon Feb 1 08:00:49 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Mon, 01 Feb 2010 09:00:49 +0100 Subject: [iolib-devel] fd handlers In-Reply-To: <20100201021552.GA466@cs.wisc.edu> References: <20100201021552.GA466@cs.wisc.edu> Message-ID: <1265011249.12428.59.camel@blackhole.cddr.org> On Sun, 2010-01-31 at 20:15 -0600, Peter Keller wrote: > Hello, > > Is there a means by which a handler registered with set-io-handler can be > "deactivated" so that it isn't considered in the fd set being checked and > "reactivated" later to be put back into the fd set? I ask because I might not > have access to the function which I want associated, say with a write handler, > but when the buffer the write handler is writing is empty. If the write > handler is always activated on an empty buffer solely because it is in the > write handler callback, then that is a performance problem. Currently there's no way to do that -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From psilord at cs.wisc.edu Mon Feb 1 17:01:49 2010 From: psilord at cs.wisc.edu (Peter Keller) Date: Mon, 1 Feb 2010 11:01:49 -0600 Subject: [iolib-devel] New collection of unchecked iolib examples Message-ID: <20100201170148.GA24175@cs.wisc.edu> Hello, In case one's curious how to use iolib, here are some unvetted examples on doing TCP/IP blocking I/O with IPV4. The program ex7-server.lisp is incomplete as of yet so ignore that one. This is for a tutorial I'm writing but which is not yet completed. I send this to the list in case I get hit by a bus or something and at least some of what I wrote makes it to the list for future people to learn from. Thank you. -pete -------------- next part -------------- A non-text attachment was scrubbed... Name: iolib-examples.tar.gz Type: application/octet-stream Size: 9221 bytes Desc: not available URL: From psilord at cs.wisc.edu Tue Feb 9 04:31:07 2010 From: psilord at cs.wisc.edu (Peter Keller) Date: Mon, 8 Feb 2010 22:31:07 -0600 Subject: [iolib-devel] with-open-socket oddness Message-ID: <20100209043107.GA4246@cs.wisc.edu> Hello, I discovered in my boundary testing of with-open-socket that it sort of has a funny behavior I didn't expect. Basically, I had a top level code like this in a blocking i/o tcp ipv4 client talking to a server: (with-open-socket (socket :stuff :things) ;; set up i/o handlers, each wrap their reads and writes around ;; handler-case. A disconnector on the sockets removes the io handlers, but ;; doesn't close the socket since with-open-socket should do it. (handler-case ;; run forever until empty (meaning we disconnected from the server), ;; then return. (event-dispatch *base*) (hangup () (format t "Hangup while writing to server~%")) (end-of-file () (format t "End of file from server~%")))) Now, what happened was, under certain conditions where there is inflight data on the sockets, a registered handler could get a signaled condition, specifically hangup, that tells me the server went away on a write. This is expected. I disconnect the socket which removes the i/o handlers, which causes event-dispatch to return since there are no registered handlers.... and then bam! The with-open-stream performs a (finish-output) and (close) on the socket and I get _another_ hangup condition! So I had to rewrite the code like this moving the handler-case up one scope: (handler-case (with-open-socket (socket :things :stuff) ;; set up i/o handlers, each wrap their reads and writes around ;; handler-case. A disconnector on the sockets removes the io handlers, but ;; doesn't close the socket since with-open-socket should do it. (event-dispatch *base*)) (hangup () (format t "Hangup while writing to server~%")) (end-of-file () (format t "End of file from server~%")))) Is this a to be expected scenario in condition handling with respect to with-open-socket? Is this idiomatic code? Should the disconnector function close the socket even though with-open-socket also closes it? I'm not sure of the right thing to do here. Thank you. -pete From sionescu at cddr.org Wed Feb 10 20:17:06 2010 From: sionescu at cddr.org (Stelian Ionescu) Date: Wed, 10 Feb 2010 21:17:06 +0100 Subject: [iolib-devel] with-open-socket oddness In-Reply-To: <20100209043107.GA4246@cs.wisc.edu> References: <20100209043107.GA4246@cs.wisc.edu> Message-ID: <1265833026.10626.9.camel@blackhole.cddr.org> On Mon, 2010-02-08 at 22:31 -0600, Peter Keller wrote: > Hello, > > I discovered in my boundary testing of with-open-socket that it sort of has > a funny behavior I didn't expect. > > Basically, I had a top level code like this in a blocking i/o tcp ipv4 > client talking to a server: > > (with-open-socket > (socket :stuff :things) > > ;; set up i/o handlers, each wrap their reads and writes around > ;; handler-case. A disconnector on the sockets removes the io handlers, but > ;; doesn't close the socket since with-open-socket should do it. > > (handler-case > ;; run forever until empty (meaning we disconnected from the server), > ;; then return. > (event-dispatch *base*) > > (hangup () > (format t "Hangup while writing to server~%")) > > (end-of-file () > (format t "End of file from server~%")))) > > Now, what happened was, under certain conditions where there is inflight > data on the sockets, a registered handler could get a signaled condition, > specifically hangup, that tells me the server went away on a write. This > is expected. I disconnect the socket which removes the i/o handlers, which > causes event-dispatch to return since there are no registered handlers.... > and then bam! The with-open-stream performs a (finish-output) and (close) on > the socket and I get _another_ hangup condition! > > So I had to rewrite the code like this moving the handler-case up one scope: > > (handler-case > (with-open-socket > (socket :things :stuff) > ;; set up i/o handlers, each wrap their reads and writes around > ;; handler-case. A disconnector on the sockets removes the io handlers, but > ;; doesn't close the socket since with-open-socket should do it. > (event-dispatch *base*)) > > (hangup () > (format t "Hangup while writing to server~%")) > > (end-of-file () > (format t "End of file from server~%")))) > > Is this a to be expected scenario in condition handling with respect to > with-open-socket? Is this idiomatic code? This is to be expected. This is what happens: one of the handlers signals a HANGUP(which is Posix EPIPE), the handler-case handles it and returns. At his point, since the code wrapped by with-open-socket returns, w-o-s closes the socket with :abort NIL, which tries again to flush the output buffer(:abort T would just close the file descriptor), which causes another HANGUP to be signaled. > Should the disconnector function close the socket even though with-open-socket > also closes it? I'm not sure of the right thing to do here. My opinion is that it's not a good idea to mix with-open-socket and the event loop because w-o-s is thought for a synchronous data flow. The only exception to that is if you use w-o-s to open the server socket. With active sockets, it's better to close them from within the event loop. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From psilord at cs.wisc.edu Wed Feb 10 20:48:13 2010 From: psilord at cs.wisc.edu (Peter Keller) Date: Wed, 10 Feb 2010 14:48:13 -0600 Subject: [iolib-devel] New iolib examples, rfc Message-ID: <20100210204812.GA25530@cs.wisc.edu> Hello, I've attached a newer version of the iolib examples I'm using for my tutorial. If people could comment upon the programs to get them more into the lisp style (except the first one or two which are C-style for a reason) or find bugs that'd be great. Thank you. -pete -------------- next part -------------- A non-text attachment was scrubbed... Name: iolib-examples.tar.gz Type: application/octet-stream Size: 10848 bytes Desc: not available URL: