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

[David Bolen]

Kragen Sitaker <kragen at pobox.com> writes:

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

True, but signals can be problematic in multi-threaded applications (I
think that was the original context at least - if not, it's still a
point :-)) and also if there's any chance the signal might interrupt
some other I/O operation than the select, since while many are
restartable, others are not.

But definitely, signaling to break a select() is certainly another
possibility in some cases under Unix.

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

As long as you can create a file descriptor that you can signal at
will, that's cool.  That's the same approach as listening on an extra
port as has been mentioned, or using a socketpair() as you comment
below.

But it should be noted that WaitForMultipleObjects can wait on more
than event objects.  It's documented to work for the following
objects:

   Change notification 
   Console input 
   Event 
   Job 
   Mutex 
   Process 
   Semaphore 
   Thread 
   Waitable timer 

For example, using a thread object signals when the thread terminates.
Same for process.  Event/Mutex/Semaphore are obvious and so on.  The
event is just a way that other types can be tied in if they can
trigger a thread.  So it's up to various kernel objects if they
support the notion of a signaled and unsignaled state, and if so, they
can be included in the call.

So in some ways I'd consider it more generic than just waiting for
read/write/exception on file handles (or device handles).  But to
address your next point you could turn it around and say that making
everything a device handle properly is even more generic.  Of course,
Unix didn't really follow through fully or we wouldn't want to
interrupt a select outside of the handles it was waiting on.

Particularly with constructs added on later (e.g., semaphores), they
don't really match the file descriptor model, at least not the last
time I used them.  E.g., you had to use sem_wait to wait for a
semaphore, not include it in a select list, so you have a similar
problem as to how to wait for both events simultaneously.

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

Oh, I certainly wasn't trying to make one system sound better than the
other.  I do think it's fair to say that the select() model is not
quite generic enough to have been found portable across the systems,
since it requires a specific underlying implementation along the Unix
device driver lines, so can be hard to reproduce on systems that don't
follow that model.  Thus the MS decision to support it for sockets,
but not try to overlay it on top of their asynchronous I/O model for
files.  But there are advantages and disadvantages to each.

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

Don't believe so.  Probably because I believe that socketpair() is
typically implemented (or limited to) UNIX domain sockets.

--
-- 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     \
\-----------------------------------------------------------------------/