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.