Timeout on read()?

[David Bolen]

"Alex Martelli" <alex at magenta.com> writes:

> Actually, it can.  WSAAsyncSelect lets you tell a socket that it
> should fire a Windows message (WM_whateveryouprefer) on
> network-events (you specify the mask of events for which that
> message will be sent).  MsgWait&tc will then 'wake up' when
> that message arrives, etc, etc.  (...)

But you have to have a message queue for this right?  Many (most
probably) of my applications don't otherwise use or require one.  Then
again, if it streamlines things, 

> (benchmarks do suggest overlapped I/O with completion
> routines is a serious win over using multiple threads for
> similar purposes; haven't looked too deeply into it since the
> code I write doesn't tend to be so strictly I/O bound anyway).

In my experience I've found that using overlapped I/O is absolutely
essential to ensure things work properly, threads or no - in all but
the simplest blocking I/O case, I/O just seems to work better under NT
with them than without.  I've managed to wedge threads on I/O (for
example, if the underlying resource disappears while an I/O is
blocked).  Just changing a straight blocking read into an overlapped
read with an immediate *blocking* GetOverlappedResult does an amazing
job at cleaning things up, without even trying to optimize the wait
for I/O into a single location for multiple streams.

> Unless you DO have these levels of performance concerns, of
> course, COM offers much handier approaches, at higher
> abstraction levels -- just hook the various events generated
> by the Winsock control object, etc, etc:-).

Well, most of my time is spent with behind the scenes low level code,
often as services, and where I want to be as tiny a burden (in as many
dimensions as possible) on the machine where I run and have as few
external dependencies as possible.  There's almost never a direct user
interface, just perhaps some remote control applications.  Even for an
in-process COM setup, it's more overhead than I'd prefer (I guess
mostly with ensuring registration since once established the pure
overhead isn't terribly worse than a DLL linkage), but it sounds like
I should play with it more for the networking stuff if only to better
judge what it might do in my environment.

> Overlapped and callbacks are not mutually exclusive... maybe I
> miss your point?

Nothing significant - just that I personally like overlapped more than
callbacks, not that they are mutually exclusive.

> I would subscribe to this, except of course that I would not expect
> ONE abstraction -- (...)
>              -- one close to the kernel, one good for scripting and
> easy to use.

Agreed - I don't mind multiple approachs (and would agree on the
minimum set of low/high) - you can pick a reasonable abstraction for
your application and be able to use it over as wide a set of resources
as possible.  To tie this back to Python, I'd guess a high level
abstraction might be a nice first step, since it would give some
freedom to the implementation to fiddle with whatever underlying
details it needed to make things work - the low level approach could
be relegated to OS-specific modules, or modules that interfaced with
the OS directly such as we already have in the win32 extensions.

> I'm not quite sure what extra it would buy me, in an event-loop
> based on MsgWait&c, if the socket was directly waitable rather
> than waking up the wait with a WM_whatever.  But then, I don't
> currently do GUI's on Unix, so, whatever little it would serve, it
> would still be more for me, too:-).

My luck, I just find myself rarely in a MsgWait with a message loop in
my applications, so just setting that up would be extra work just to
deal with the sockets.  Ok, it's not that big a deal, but I can still
be annoyed :-)

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