[Sbcl-help] CL:LISTEN on a service socket that has reached EOF

[Stephen C. <ste...@gm...>]

My issue with SBCL's CL:LISTEN is that it seems to return T on service
sockets when -- but not before -- the peer has closed the connection, even
when there are no more characters to read, unless I have tried to read a
character.

To see this in action, please load:

http://csserver.evansville.edu/~sc87/dist/sbcl-listen-socket-test.lisp

And call the thunk NOCANDY-USER::TEST-SOCKET-CL-LISTEN.  If you are
familiar with the thread and network code in SWANK-BACKEND, the functions
should be familiar; they are there so I can test this on OpenMCL if I can
find an installation.  Please note that it requires threads to work; to
see this without threads, in SLIME, see:

http://article.gmane.org/gmane.lisp.slime.devel/4551

On my system (Linux nocandy.dyndns.org 2.6.12-12mdk #1 Fri Sep 9 18:15:22
CEST 2005 i686 AMD Athlon(tm) XP 2800+ unknown GNU/Linux), running SBCL
0.9.9 with threads, the assertion (eq nil (listen service)) consistently
fails, unless I uncomment the PRIN1 (i.e. READ-CHAR) call above it.  PRIN1
prints NIL in that case.

From my limited understanding of the SBCL source, the underlying system
call driving CL:LISTEN for sockets (fd-streams) is select(2), through
unix-fast-select, through fd-stream-misc-routine in fd-stream.lisp.  My
select(2) man page says that select returns when a READ-FD is at EOF; this
does not explain why CL:LISTEN implements the behavior I expect after
attempting to read another character, however.

Thanks in advance for any advice, LARTing for one or more silly
assumptions above, etc.

-- 
Stephen Compall
Email: My username is s11.  My domain is member..org, but insert the
abbreviation for `Free Software Foundation' between the dots.