Peter Hansen wrote: > Ivan Voras wrote: >> Python is bad for concurrently executing/computing threads, but it >> shouldn't be that bad - do you have lots of compute-intensive threads? > > Just in case anyone coming along in the future reads this statement, for > the record I'd like to say this is obviously a matter of opinion or > interpretation, since in my view Python is *excellent* for threads
Ivan already gave his answer: the GIL. The GIL is no real problem on single processors. As commodity machines go to multi-poly-hyper-cell-core, or whatever they call it, the GIL is becoming much less attractive. There are other issues of note: As the OP's problem points out, Python threads don't offer any priority control. Timeouts on the threading module's Condition objects are implemented by active polling. Timeouts in threading.Event and Queue.Queue are implemented via threading.Condition so they inherit the polling implementation. A thread can wait on just one Lock/RLock/Condition/Semaphore/Event/Timer at a time. There is no analog of Win32's WaitMultipleObjects(). As an example, suppose we wanted to implement timeouts without polling by waiting for either a Semaphore or a timer. With Python's standard thread and threading libraries, there's no good way to do so. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
