AW: Re[2]: [clisp-list] socket-shutdown and broken http inspect s erver o n win32

[Hoehle, Joerg-C. <Joe...@t-...>]

Hi,

Todd wrote:
>Setting the SO_LINGER option for all sockets whether they want it or
>not, and giving no way of turning it off doesn't seem like the right
>thing to me.
Hmm. Ideally, users wouldn't and shouldn't care.
In some way, LINGER is user-visible, since they may notice that CLOSE may take half an eternity.
Nevertheless, a reasonable behaviour for CLISP is to favour reliability of transmission -- to some extent, e.g. typically, CLOSE will not signal errors, or it cannot signal errors because it cannot even know.

It's not unlike a file system: you, as a programmer, cannot rely on open("/user/foo/bar"); write(); close() - even with full error checking - to actually have written something to disk. fflush() won't help either.  Most disk and driver systems these days will implement delayed writes, sometimes as much as 30 seconds later. The individual application gets no feedback about that.


Arseny wrote:
>You can use shutdown(). Setting socket options on close is like a
>hack.
I fail to see why this is a hack, please explain. I can find no place which says "setsockopt() is only allowed before you really use a socket so you must put it at start". LINGER only affects close() behaviour, not even shutdown().

Using a situation-dependent setsockopt(LINGER) at CLOSE time is what seems right to me. Especially since it fits nicely with the CLOSE :ABORT keyword. That's how users *can* control lingering, which is what Todd expects to be able to do.

I believe it would be reasonable to call shutdown(SD_SEND) before closesocket(), even with lingering. An extra shutdown() doesn't cost much and it's specifically recommended. Of course, with such broken MS-Woes TCP/IP, one has to wonder what happens on a shutdown(SD_SEND) on a socket that CLISP only used for reading so far...


Todd Sabin wrote:
>How sure are you that this is actually necessary?  It seemed that this
>problem showed up at the same time as the problem which turned out to
>be due to an incorrect Content-Length: header.  Maybe that was
>actually the only bug, and SO_LINGER is in fact not needed at all?

No. Content-Length is/was a bug on its own.
The CLOSE problem appears with any socket communication. Not just inspector's HTTP.
I used the inspector in examples because everybody has it.

Regards,
	Jorg Hohle.