[Python-Dev] RE: delayed I/O; multiple waits

[Mark Hammond]

> You lost me when you said it should be optional -- that's fine for an
> extension module, but it sounded like you wanted this to

Cool - I admit I knew it was too vague, but left it in anyway.

> the language core.  If WaitForMultipleObjects (which is what
> you *really*

Sort-of.  IMO, the threading module does need a WaitForMultipleObjects
(whatever the spelling) but <sigh> I also recall the discussion that this
is not trivial.

But what I _really_ want is an enhanced concept of "waitable" - threading
can only wait on locks and threads.  If we have this, the WaitForMultiple
would become even more pressing, but they are not directly related.

So, I see 2 issues, both of which usually prevent me personally from using
the threading module in the real world.

By "optional", I meant a way for a platform to slot into existing
"waitable" semantics.  Win32 file operations are waitable.  I dont really
want native win32 file operations to be in the core, but I would like some
standard way that, if possible, I could map the waitable semantics to
Python waitable semantics.

Thus, although the threading module knows nothing about win32 file objects
or handles, it would be nice if it could still wait on them.

> needs-more-words-ly y'rs  - tim

Unfortunately, if I knew exactly what I wanted I would be asking for
implementation advice rather than grasping at straws :-)

Attempting to move from totally raw to half-baked, I suppose this is what I
had in mind:

* Platform optionally defines what a "waitable" object is, in the same way
it now defines what a lock is.  Locks are currently  _required_ only with
threading - waitables would never be required.
* Python defines a "waitable" protocol - eg, a new "tp_wait"/"__wait__"
slot. If this slot is filled/function exists, it is expected to provide a
"waitable" object or NULL/None.
* Threading support for platforms that support it define a tp_wait slot
that maps the Thread ID to the "waitable object"
* Ditto lock support for the plaform.
* Extensions such as win32 handles also provide this.
* Dream up extensions to file objects a-la Jack's idea.  When a file is
opened asynch, tp_wait returns non-NULL (via platform specific hooks), or
NULL when opened sync (making it not waitable).  Non-asynch platforms need
zero work here - the asynch open fails, tp_wait slot never filled in.

Thus, for platforms that provide no extra asynch support, threading can
still only wait on threads and locks.  The threading module could take
advantage of the new protocol thereby supporting any waitable object.

Like I said, only half-baked, but I think expresses a potentially workable
idea.  Does this get closer to either a) explaining what I meant, or b)
confirming I am dribbling?

Biggest problem I see is that the only platform that may take advantage is
Windows, thereby making a platform specific solution (such as win32event I
use now) perfectly reasonable.  Maybe my focus should simply be on allowing
win32event.WaitFor* to accept threading instances and standard Python lock
objects!!

Mark.