From: Stephen Compall <stephen.compall@gm...> - 2006-02-02 03:02:12
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
To see this in action, please load:
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:
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.
Email: My username is s11. My domain is member..org, but insert the
abbreviation for `Free Software Foundation' between the dots.
Get latest updates about Open Source Projects, Conferences and News.