Timeout on read()?

[Alex Martelli]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:u7l97u5h5.fsf at ctwd0143.fitlinxx.com...
    [snip]
> But MsgWaitForMultipleObjectsEx still can't merge everything (e.g.,
> sockets), which tended to be a show-stopper for me where most of my
> applications have at least one network connection involved.  Which

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.  This is the approach I normally
follow when I have to program low-level message loops, since
I normally may have WM_somethings coming in from other
sources as well (e.g., service-control-manager serialization of
COM calls from other processes/threads).

Further, since you're using the ...Ex version, it will also wake
up on I/O completion or asynchronous procedure call (APC),
and you can specify overlapped-IO and completion routines
with WSPSend & friends, just as you can for the Ex versions
of other I/O calls.  I haven't tried this one, but it might offer
half an epsilon extra performance if you're seriously I/O bound
(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).

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


> >                     Maybe we need one, more abstract, primitive,
> > to be _built_ in terms of select (or poll?) on Unix, in terms
> > of MsgWait&tc on Windows; that might avoid saddling either platform
> > with the inefficiencies of the other (if the lower-level, platform
> > typical construct was chosen as the 'primitive').
>
> It's indeed an interesting design question.  I'm also not convinced
> that select() is the only appropriate high level model (in fact, I
> sort of like Win32's overlapped I/O mechanism - callbacks are ok too,
> but I like the fact that you're in control of the synchronization of
> the handling of the overlapped I/O).

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

> To some extent, I'm less concerned with precise implementation than I
> am with the desire that such an implementation provide a homogenous
> abstraction that is applied consistently on the platform.

I would subscribe to this, except of course that I would not expect
ONE abstraction -- lower-level things for performance-hungry programs
may well be harder to use than higher-abstraction ones, and I would
give up neither the performance (for those rare crucial cases where
it's needed) nor the ease of use (for those frequent cases where I
want an easy life:-).  So, in the best case, I would expect *two* such
abstractions -- one close to the kernel, one good for scripting and
easy to use.


> > > Oh well - hope isn't high for me - they've had plenty of time, and I
> > > don't think this changes in W2K either.
> >
> > Right, I don't think it changes one whit, either.  Just as I
> > don't think specific GUI windows will be mapped to descriptors
> > directly usable in select on any soon-coming Unix dialect:-).
>
> Yeah, but I'd get a lot more mileage and far fewer headaches if they'd
> fix sockets in Win32 than I would if they fixed GUI windows on Unix
> ;-)

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


Alex