
I think this is exactly what I _didn't_ want:-) I'd like the delayed read to return an object that will automatically wait when I try to get the data from it, and the delayed write object to automatically wait when I garbage-collect it. Of course, there's no reason why you couldn't also wait on these objects (or, on unix, pass them to select(), or whatever). On second thought the method of the delayed read should be called read() in stead of get(), of course. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

[I missed Jack's point]
OK - that is fine. My driving requirement was that I be able to wait on _multiple_ files at the same time - ie, I dont know which one will complete first. There is no reason then why your initial suggestion can not satisfy my requirement, as long as the "buffer type object" returned from read is itself waitable. I agree there is no driving need for a seperate buffer type object and seperate waitable object necessarily. [OTOH, your scheme could be simply built on top of my scheme as a framework] Unfortunately, this doesnt seem to have grabbed anyone elses interest.. Mark.

[Mark Hammond]
... Unfortunately, this doesnt seem to have grabbed anyone elses interest..
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 somehow be part of the language core. If WaitForMultipleObjects (which is what you *really* want <wink>) is thought to be a cool enough idea to be in the core, we should think about how to implement it on non-Win32 platforms too. needs-more-words-ly y'rs - tim

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.

[I missed Jack's point]
OK - that is fine. My driving requirement was that I be able to wait on _multiple_ files at the same time - ie, I dont know which one will complete first. There is no reason then why your initial suggestion can not satisfy my requirement, as long as the "buffer type object" returned from read is itself waitable. I agree there is no driving need for a seperate buffer type object and seperate waitable object necessarily. [OTOH, your scheme could be simply built on top of my scheme as a framework] Unfortunately, this doesnt seem to have grabbed anyone elses interest.. Mark.

[Mark Hammond]
... Unfortunately, this doesnt seem to have grabbed anyone elses interest..
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 somehow be part of the language core. If WaitForMultipleObjects (which is what you *really* want <wink>) is thought to be a cool enough idea to be in the core, we should think about how to implement it on non-Win32 platforms too. needs-more-words-ly y'rs - tim

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.
participants (3)
-
Jack Jansen
-
Mark Hammond
-
Tim Peters