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

[Kragen Sitaker]

David Bolen <db3l at fitlinxx.com> writes:
> 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.

Or use a signal.

In Unix, nearly everything (with the exceptions of SysV IPC message
queues and semaphores and child process status changes) that can
generate events are already file descriptors; if you're communicating
with another cooperating process, you're probably already doing it
with a file descriptor, so it fits into select() neatly.

Signals fit into this rather poorly, but they do interrupt select()
and cause the appropriate handler to run, which is generally what you
need.

> 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.

Consider the following:

But all of those approaches are really ways to try to work around the
fact that WaitForMultipleObjects (sp?) only works on signaling of
event objects.  With Unix native functions, I'd just define an extra
file descriptor, and wait on that file descriptor along with the file
descriptors related to the sockets.  To shut it down, just signal the
special file descriptor.

I think the difference is just in how you look at things.

> It's interesting that all of these approaches do have one thing in
> common - they tend not to be portable.

Does Winsock not have socketpair()?  My Win32 API references are all
in another state.