3: (SB-UNIX::NOTE-DANGEROUS-SELECT) 4: (SB-IMPL::SUB-SUB-SERVE-EVENT NIL NIL) 5: (SB-IMPL::SUB-SERVE-EVENT NIL NIL NIL) 6: (SB-SYS:WAIT-UNTIL-FD-USABLE 13 :INPUT NIL) 7: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "a socket" {100338FE81}>) 8: (SB-IMPL::INPUT-UNSIGNED-8BIT-BYTE #<SB-SYS:FD-STREAM for "a socket" {100338FE81}> T NIL) 9: (CL-POSTGRES::READ-UINT1 #<unavailable argument>)
fyi, we have a postmodern branch which has a patch to make it use iolib as the socket backend. we also had some issues with sb-bsd-sockets before...
i CC the postmodern list to give another data point why it's a good idea to have iolib as the socket backend.
http://dwim.hu/darcsweb/darcsweb.cgi?r=HEAD%20postmodern;a=summary
or
darcs pull http://dwim.hu/darcs/postmodern/
hth,
Hi Attila,
The changes required to use iolib instead of usocket are very tiny. That's great. If only there was some widely-supported, nice way of parameterised module loading. I don't want to simply incorporate your patch as it is -- that'd break windows support. One approach would be a feature :postmodern-use-iolib that people can push onto *features* before loading Postmodern, and conditionally replaces references to usocket with iolib. Would that work for you?
As for replacing force-output with finish-output, why did you do that? It seems like it might slow some things down, and unless I am missing something, finish-output does the job.
Best, Marijn
On Tue, 2009-10-06 at 11:30 +0200, Marijn Haverbeke wrote:
Hi Attila,
The changes required to use iolib instead of usocket are very tiny. That's great. If only there was some widely-supported, nice way of parameterised module loading. I don't want to simply incorporate your patch as it is -- that'd break windows support. One approach would be a feature :postmodern-use-iolib that people can push onto *features* before loading Postmodern, and conditionally replaces references to usocket with iolib. Would that work for you?
what about depending on usocket on windows and iolib on *nix ?
As for replacing force-output with finish-output, why did you do that? It seems like it might slow some things down, and unless I am missing something, finish-output does the job.
CLHS says:
finish-output attempts to ensure that any buffered output sent to output-stream has reached its destination, and then returns.
force-output initiates the emptying of any internal buffers but does not wait for completion or acknowledgment to return.
On SBCL(and probably most other implementations) they are equivalent. For iolib I took the CLHS to the letter and only finish-output blocks until all buffered data is written, while force-output only sets a flag that the stream must be flushed by the next blocking operation
Hi Stelian,
finish-output attempts to ensure that any buffered output sent to output-stream has reached its destination, and then returns.
force-output initiates the emptying of any internal buffers but does not wait for completion or acknowledgment to return.
I know. The situation that we want to avoid is CL-postgres calling read on a socket that has unflushed data -- then both the server and the client will wait forever. Thus, it is enough to call force-output, which ensures that the flushing is initiated, and the next read won't block forever.
Best, Marijn
On Tue, 2009-10-06 at 12:14 +0200, Marijn Haverbeke wrote:
Hi Stelian,
finish-output attempts to ensure that any buffered output sent to output-stream has reached its destination, and then returns.
force-output initiates the emptying of any internal buffers but does not wait for completion or acknowledgment to return.
I know. The situation that we want to avoid is CL-postgres calling read on a socket that has unflushed data -- then both the server and the client will wait forever. Thus, it is enough to call force-output, which ensures that the flushing is initiated, and the next read won't block forever.
Iolib socket streams don't flush the output buffer on reading. that would lead to major complications in order to be made safe
On Tue, 2009-10-06 at 20:48 +0200, Marijn Haverbeke wrote:
Iolib socket streams don't flush the output buffer on reading. that would lead to major complications in order to be made safe
Aren't they kind of going against the CL standard, then?
Not as fair as I know. I read the entire stream chapter when I wrote it and I remember no such requirement
Iolib socket streams don't flush the output buffer on reading. that would lead to major complications in order to be made safe
Aren't they kind of going against the CL standard, then?
Not as fair as I know. I read the entire stream chapter when I wrote it and I remember no such requirement
The only thing I can find in the hyperspec is:
force-output initiates the emptying of any internal buffers but does not wait for completion or acknowledgment to return.
So I think your force-output should do at least *something* that, in the finite future, causes the buffers to be flushed. In case of emergency, you can just make force-output and finish-output equivalent.
(As in, I'm not too anxious to modify my code unless there's a good reason to do so. Going by the Hyperspec, I think using force-output like that should be correct.)
Hi Attila,
hello Marijn,
The changes required to use iolib instead of usocket are very tiny. That's great. If only there was some widely-supported, nice way of parameterised module loading. I don't want to simply incorporate your patch as it is -- that'd break windows support. One approach would be a feature :postmodern-use-iolib that people can push onto *features* before loading Postmodern, and conditionally replaces references to usocket with iolib. Would that work for you?
i think i would prefer a cl-postgres+iolib.asd. but then that leads to the question how to handle the situation of using babel for string encoding... that quickly leads to an exponential blow up.
maybe iolib.asd itself pushing :iolib into *features* and conditionalizing the :depends-on on #+iolib?
i really don't have a clean idea on how to do it, that's why i was quiet about the merge of this patch into cl-postgres proper. meanwhile i hope that darcs pull will keep my life simple because the divergence is small...
this situation again makes me think that asdf is plain wrong and a goddamn defun based interface would be much more flexible. then it'd be a matter of another &key arg...
postmodern-devel@common-lisp.net
-
Attila Lendvai -
Marijn Haverbeke -
Stelian Ionescu