Timeout on read()?

[Alex Martelli]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:uvgwtrliz.fsf at ctwd0143.fitlinxx.com...
> Donn Cave <donn at u.washington.edu> writes:
>
> > Probably true, and the same is still true for BeOS.  But on the
> > bright side, select() is the best way to go on UNIX.  And
optimistically,
> > we can hope that the notion of file descriptor as a valuable abstraction
> > will catch on
>
> I wish - this has to be way up there for me on my list of frustrating
> things about Windows development.  I mean, for just about everything
> they did build this abstraction (e.g., most other resources being
> standard HANDLEs).  Why couldn't they have implemented Winsock as a
> filesystem (as they did their own WNet stuff) and thus have it return
> handles compatible with the all the other handles in the Windows
> universe?

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

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.

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

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


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.  In a Unix 'select', typically, each socket can
have its own separate select-able descriptor, but all the X11
(thus, GUI) activity is mapped to just one descriptor; to let
other objects (threads, processes, IPC thingies) participate,
you have to build some mapping between what you actually want
to select-on (e.g., a process terminating) and actual activity
on a descriptor. In the above hypothetical almost-equivalent
Windows construct, sockets as well as windows (and such things
as window-based timers) would also map to that 'one descriptor',
but processes, threads, and termination of some async I/O would
each have a separate 'descriptor'.  Neither construct seems to
be general enough.  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').


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


Alex