readline() blocks after select() says there's data??

[David Bolen]

grante at visi.com (Grant Edwards) writes:

> TCP/IP networking that was pasted on as an afterthought, and
> that's when select came into the picture.

Well, the IP stack came later but with the current WinSock2 there's a
pretty flexible architecture for protocols and service providers which
isn't too bad, and IP is just one of the "providers".  So multiple
network stacks (not just IP) can be treated the same.

> Are TCP/IP connection native kernel objects?

In a literal sense I'd have to say no - you don't get a kernel handle
to them (at least at the application level).  I'm sure they have some
internal handles they managed, but the socket itself is a higher level
abstraction managed by the winsock library.

However, Win32's winsock does provide clean ways to tie them to
signaling kernel objects (events) which let's them play equally (be
processed simultaneously) with other kernel objects to signal
completion of operations.  And that's pretty much the same way that
asynchronous file I/O works, providing an event object for completion.
So in practical terms, they behave just as other resources do for I/O
when using the Win32 functions.

Of course, to make this work you need to use the Win32 aware
(Microsoft extensions) version of the socket functions, which of
course are non-portable.  But that would let you incorporate socket
selections as well as waiting for file, pipe, mailslot, etc... or any
other I/O or events simultaneously.  It's not the same as the Unix use
of 'select' but that gets to the question of the basic underlying
model differences between Unix v. Win32 as opposed to better or worse.

In some ways for most uses I find the Unix approach more streamlined,
but there are times when the Win32 approach is more flexible.  For
example, Unix select can only wait on file handles for
read/write/exception.  Under Win32 you typically set up asychronous
activities and then wait on a collection of event objects (or other
native objects that can signal themselves).  You can easily add in
your own event objects into the mix for any arbitrary signaling.

In more concrete terms (and more to the context of this thread), it
provides perhaps a cleaner approach to interrupting the blocked
select.  With select you might try to forceably interrupt the select
by closing the socket, or sending fake data to another (or the same)
socket, or having a fairly quick timeout and check for a flag.  But
all of those approaches are really ways to try to work around the fact
that select only works on I/O operations to file handles.  With Win32
native functions, I'd just define an extra event object, and wait on
that event object along with the event objects related to the sockets.
To shut it down, just signal the special event object.

It's interesting that all of these approaches do have one thing in
common - they tend not to be portable.  I think it basically shows
that the pure sockets-based select() model, which is really what
different systems have standardized on as portable, just doesn't
address this aspect of things well, thus needs along these lines tend
to devolve into platform-specific solutions.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/