Timeout on read()?

[Alex Martelli]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:uaee3mqsm.fsf at ctwd0143.fitlinxx.com...
> "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?

Yes, a message-queue and event-loop are needed to do full-fledged
event-driven processing on Windows.

> Many (most
> probably) of my applications don't otherwise use or require one.  Then
> again, if it streamlines things,

I think it does, particularly if you're trying to avoid threading
in favour of eventing.  The Service Control Manager, for example,
can transparently (well, almost-transparently) turn requests that
come from other processes on your COM objects into a single-threaded
queue -- but it does need you to serve a message-queue for that.

Other important notifications come via message-queue, too.  For
example, WM_ENDSESSION is the best way for your application to
learn that the system is being shut down (IMHO); you probably do
want to do some last-moment emergency work under such circumstances
(you can also ask for the system to NOT shut down, if you serve
your message queue, by handling WM_QUERYENDSESSION too).  If
your application's settings depend in any way on system parameters
(e.g., power-saving settings), then you probably want to keep an
eye on WM_WININICHANGE, too.  If you run on /95 or /98 (not needed
on NT/2000), and need to keep track of what user is logged on or
off, you probably want to serve WM_USERCHANGED.  Etc, etc.


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

You clearly have more experience with overlapped I/O on NT, than
I have, so, thanks for sharing this experience!  What about
asynchronously called completion routines -- how good/bad/reliable/&c
have you found them, if you've tried them out?


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

Yes, the speed of in-process COM communication is excellent, particularly
if you use lower-level COM approaches (the interpretive overhead on
Automation, the need to have data formatted in certain ways, etc, makes
speed less-than-amazing for higher-level approaches, of course:-).  The
need to ensure things that you need are in fact registered may be an
issue during the installation phase of your application, but it's really
no worse than checking for whatever other components you need to be at
'certain-level-or-better', be it winsock, odbc, whatever.

> I should play with it more for the networking stuff if only to better
> judge what it might do in my environment.

Experimenting with these things is often a good investment of one's
time, particularly as the published data about them not always match
reality, and hard performance data specifically are rarely published.


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

Overlapped makes it easier/more-natural to have a single 'funnel'
point for event dispatching, I guess.  That does come in handy at
times.  With an event/message-loop, that single-funnel comes back,
in a sense.


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

We are in violent agreement, it seems.


> > 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 :-)

You sure you don't need to know when the machine is about to shut
down, change operating parameters, etc?  If you do, the message
loop is good to have anyway, so it's not any extra work for sockets...:-)


Alex