WaitForMultipleObjects in Python.

David Bolen db3l at fitlinxx.com
Fri Jul 9 14:26:07 EDT 2004


elbertlev at hotmail.com (Elbert Lev) writes:

> > For example, when I wanted a SerialIO object that supported full
> > non-blocking I/O to the serial port under Windows, I ended up
> > implementing a thread using overlapped I/O with
> > WaitForMultipleObjects.  There just wasn't any equivalent in portable
> > Python.
> 
> Strange. Why did you neen multiple threads? You could use Overlapped
> I/O and IOCP (on Windows).

Um, right, that's what I said I did (overlapped I/O).  But obviously
the thread doing the overlapped I/O (and the WaitForMultipleObjects)
has to be distinct from the main Python thread of execution, since
it's blocked in the WaitForMultipleObjects call.  So you still need at
least one background thread - at least if the application code expects
to actually do anything with the data being moved around.  (The one
exception to this would probably be an app whose sole purpose is I/O
itself, but my SerialIO object wasn't intended to stand alone).

> Let's be practical. For most cases server/worker thread model is what
> you need. So queue communication is adequite. The only problem as I
> see is that it is not Python Queue.Queue, but priority queue (waist in
> this case), or a subclass of Queue.Queue, which allows to
> post-to-head. I  understand, that this is NOT THE SAME AS
> WaitForMultipleObjects, but close enough, for every day usage. If this
> is not what you want, you probably are using a wrong language for the
> job.

It's close enough for many uses, but not for all.  But I disagree that
such a statement must imply a wrong language choice.  Python has a
selected set of synchronization primitives and supporting functions.
The very fact that there are any in the standard library certainly
means, to me, that there can and should be discussions as to whether
it has a reasonable set, without having to jump right to "switch
languages."

-- David



More information about the Python-list mailing list