Re: sockets

[Sam S. <sd...@gn...>]

> * Todd Sabin <gf...@bc...g> [2005-05-20 11:15:59 -0400]:
>
> David Tolpin <dv...@da...> writes:
>
>> On 20.05.2005, at 15:20, Bruno Haible wrote:
>>
>>> No. David pointed out that two things are wrong in the current
>>> implementation:
>>>   - (CLOSE socket) causes loss of data.
>>>   - Users need to know about the SOCKET-SERVER-SHUTDOWN function.
>>> We should fix both simultaneously, by having CLOSE call shutdown().
>
> There is certainly no general requirement to perform a shutdown()
> before a close() on linux.  With correct clients and servers, shutdown
> is usually not needed.

I hoped this was the case...

>> If CLISP is committed to provide access to the Unix semantics,
>> shutdown should shut down and close should close, at least in some of
>> their invocations.
>
> I agree with this.  clisp's shutdown should not close the stream, nor
> should stream close perform a shutdown, in the normal case.  If the
> application wants that, it can do it itself.

Agreed!

>> I'd propose to keep socket-stream-shutdown but remove call to
>> builtin_stream_close from there, and respect :ABORT in close, calling
>> shutdown if :ABORT is nil. This way, the default mode of operation
>> would be to allow users to write programs which behave as expected,
>> and when the user needs to write a server with abrupt close, she calls
>> (close socket :abort t) letting the server send RST if there is still
>> data.
>
> Calling shutdown in the (close socket :abort nil) case is wrong, I
> think.  It might be needed in the :abort t case.

Hmmm...  :ABORT T means "try to restore the status quo ante".

Note also that CLISP tries to CLOSE all open file and socket streams on
exit, and getting an error there means that the user cannot quit CLISP.
(Actually, I think this should be handled by installing a global error
handler in close_all_files()).
OTOH, <http://www.lisp.org/HyperSpec/Body/fun_close.html>
says "Exceptional Situations: None.", so signaling an error in CLOSE is
probably not a good idea anyway...

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.honestreporting.com> <http://www.mideasttruth.com/>
<http://www.memri.org/> <http://www.openvotingconsortium.org/>
In the race between idiot-proof software and idiots, the idiots are winning.