Re: clisp-cvs Digest, Vol 59, Issue 7 - econnreset

[<don...@is...>]

Sam Steingold writes:
 > > * Don Cohen <qba...@vf...> [2011-04-10 09:54:25 -0700]:
 > >
 > > This is the case where a third output value similar to eof would be
 > > useful.
 > 
 > http://www.cygwin.com/acronyms/#PTC
This seems to be closely related to the next msg about error return
from socket-status and doc.

My first suggested patch would be to move this statement close to the
top of the doc.
  This is the interface to select (on some platforms, poll) ...
Then to change
  We define status for a SOCKET:SOCKET-SERVER or a SOCKET:SOCKET-STREAM
  to be :ERROR if any i/o operation will cause an ERROR.
to 
  Socket-status returns :error if select finds an exceptional condition
  pending on any of the argument streams.
(or some other version of that statement that is actually true - this 
is how I interpreted your reply to the doc complaint).

http://pubs.opengroup.org/onlinepubs/009695399/ is not very helpful
here.  It says

  If a socket has a pending error, it shall be considered to have an
  exceptional condition pending. Otherwise, what constitutes an
What counts as a pending error?  RST?  EOF?

  exceptional condition is file type-specific. For a file descriptor for
  use with a socket, it is protocol-specific except as noted below. For
  other file types it is implementation-defined.
And then below:
  A socket shall be considered to have an exceptional condition
  pending if [...  out-of-band data is pending]
(I don't think I've ever even heard of the OOB feature being used.)
  Other circumstances under which a socket may be considered to have
  an exceptional condition pending are protocol-specific and
  implementation-defined.

So I still have no ideas how to cause socket-status to return :error
other than possibly trying to send OOB data.
If any are known or discovered, I'd appreciate some mention of them
in impnotes, and if none are known, it might be worth mentioning that
as well.

Also, it occurs to me to ask about this statement:
  Additionally, for a SOCKET:SOCKET-STREAM, we define status in the
  given direction (one of :INPUT, :OUTPUT, and :IO) to be
Does all this apply as well to other (non-socket) streams?
If you're just calling select, I'd expect so.  In which case the
statement should be generalized.

 Note that SOCKET:SOCKET-STATUS may SIGNAL a STREAM-ERROR. This happens
 if the SOCKET:SOCKET-STREAM receives an RST packet, see
 tests/econnreset.lisp. 
This seems weird.
After the reset I get:
 [45]> (socket-status s)

 [../src/stream.d:6196] 
 *** - UNIX error 104 (ECONNRESET): Connection reset by peer
 The following restarts are available:
 ABORT          :R1      Abort main loop

but then 
 Break 1 [46]> (socket-status s)
 :APPEND ;
 1
 Break 1 [46]> 

I'd have expected that the two successive calls (with no activity on
the socket in between) would have acted the same.

I guess this is related to the fact that if I try to read this stream
then I get ECONNRESET the first time and EOF the second time, which
I also find weird.  

Does the term "pending error" have something to do with whether the
error has been reported by setting errno before?

 > > The result should encode the fact that neither input nor
 > > output can be done on this stream ever again.
 > 
 > I thought that :ERROR was for that.
 > That's what I expected.

I guess that depends on what select does in this case, and that seems
depend on what it means for a socket to have a pending error, or else
to be implementation defined.

 > Actually, the fact that select() does not set the error bit for the
 > socket appears to indicate that the socket is not completely and
 > terminally dead after ECONNRESET.

Is "completely and terminally dead" supposed to be a technical term?
It is clear that after a reset you can't get more input or send more
output on the stream.  But the lisp stream is still open, so in that
sense it's not completely dead.

 > > Which machines return which values?
 > 
 > :APPEND ubuntu 10.10
 > Linux 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:39:03 UTC 2011 x86_64 GNU/Linux
 > 
 > :EOF CentOS release 5.5 (Final)
 > Linux 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
 > 
 > what do your machines do?
The append result above comes from fedora 14.  I've not yet tried the
older linux version. 

 > > Is this test supposed to fail in one case and succeed in the other?
 > all tests are always expected to succeed.

    2.26 -(:OUTPUT "foo" :OUTPUT STREAM-ERROR :EOF ERROR :EOF END-OF-FILE)
    2.27 +(:OUTPUT "foo" :OUTPUT STREAM-ERROR NIL ERROR NIL END-OF-FILE)
What does this mean in terms of whether append is considered successful?

 > > [BTW, I now see that the diffs can be viewed by doing
 > >  hg log -v -p  |more
 > > ]
 > 
 > you can also click on
 > 
 > >  > details:   http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/clisp/rev/83c307059ea7

Thanks.