Timeout on read()?

[David Bolen]

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

> Winsock was born back when Windows (3.0 at the time, I believe) lay
> over a DOS 'kernel'.  Being able to obtain generic HANDLE for 'kernel
> objects' is a more recent development, dating back to the later
> Windows NT kernel, and, in Windows proper, to the even-later imitation
> of some of said kernel's functionality (the 'core Win32 APIs') on top of
> a modified Dos kernel (the 'Windows95' product).
> 
> As a result of all this, Winsock lives in user-space, HANDLE's are
> only generated by/for kernel-objects, and NT has no generic way for
> user-space code to masquerade as kernel-space (implement filesystems,
> or otherwise generate/handle kernel-objects).

All true - I only wish that when WNet was being taken care of to be
able to work as HANDLEs (since clearly even the original Windows
networking predates HANDLEs as well back from the original
NETBIOS/Lanman days) that they also included Winsock as just an
important a networking layer.  But to be fair, it probably wasn't
quite there in the Microsoft world at the time in the same way as it
is now.

> Note, by the way, that windows, timers (of the ordinary kind, the
> kind that's implemented on top of a window with a WM_TIMER message),
> and a few other such things, are also not kernel-objects.  You may
> call a window-reference 'a handle', but that doesn't mean you can
> WaitForOneObject on it (expecting it to be signaled when it receives
> a WM_whatever message).  The reason is very similar -- all of these
> objects pre-existed the Windows NT kernel, just as Winsock sockets
> did.  Legacy/compatibility constraints seriously hampered any chance
> of unification, again in part because of there being no good way
> to build kernel-level thingies out of user-space code.

Yep - while Windows (once NT showed up) has at least attempted to have
a unified kernel object model, I remember the first time I pulled up
the MSDN page for WaitForSingleObject and ended up spending quite some
time following a whole slew of links to get a good handle on all the
caveats involved with various types of object handles.  I mean, it's a
non-trivial problem (and as you say, nasty/impossible for backwards
compatibility in some cases), so I guess it's not that horrible an
implementation, but somehow I just wish it was more uniform.

Unix may have it's incompatible structures/handles as well, but when
working in that environment, somehow it feels as if those are the
exception rather than the rule.  I don't always get that feeling with
Win32.

> On the bright side -- it *should* be possible, and reasonably easy,
> to implement select-like functionality on a mixture of winsockets
> (and other user-space objects, that cannot be Wait'd upon but can
> receive WM_something messages) and kernel-objects (real HANDLEs).
> MsgWaitForMultipleObjectsEx is the system-call that 'merges' the
> heterogeneous kinds of objects (ones that are Wait'able, ones that
> receive WM_ messages, I/O completions and asynch procedure calls).

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
sort of gets back to my original point - while still not perfect, if
at least sockets could play on the same field as the other handles, it
would cover a large majority of my cases where I currently end up
independently threading the socket work, or building more wrapper code
than I would like to have to do.

If you've ever used the Cygwin system under Windows, it manages to
mimic the Unix semantics by identifying the selection of 'files' that
you are trying to select on, and bucketing them into groups that share
a common mechanism under Win32.  It then spits off independent
threads, each of which wait appropriately for their group, and then
synchronize back up when something fires.  It's sort of annoying to
have to go through though, at least at an intellectual level :-)

> If you've ever worked on Unix System V, and had a similar problem
> of synchronization between heterogeneous objects -- ones mapped
> into filedescriptors, such as sockets, and others NOT so mapped,
> such as the various IPC primitives System V was cursed with -- you
> will surely recognize the issues (except that the System V designers
> had less justification in my opinion, since filedescriptors DID
> already exist in the Unix kernel when they decided to use other
> heterogeneous mechanisms for semaphores, shared-memory, queues...).

Definitely - that's just someone coming up with a new subsystem and
seemingly ignoring a perfectly good kernel interface.  I'm not sure if
it was NIH syndrome of some sort, or just a missed neuron firing.

> Of course, 'easy' is a relative term.  And it's not clear how
> Python could portably take advantage of such a construction if
> it did come.  (...)
>                     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).

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.

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

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