On 2008-10-21, sokol <tv***************@gmail.comwrote:
On Oct 21, 2:19*am, greg <g...@cosc.canterbury.ac.nzwrote:
>sokol wrote:
What was a surprise to me was that python sched.py makes the same
mistake as I did in my first version.
The sched module is *not* designed for multithreading. It
assumes that the thread waiting for events is the only one
putting events into the queue, so it's impossible for an
event to get scheduled while in the midst of a sleep. It
also doesn't take any measures to protect its data structures
from concurrent access.
The documentation could make this clearer, especially since
it confusingly talks about "allowing other threads to run".
I find that hard to believe. Scheduler in single threaded
application is useless (well, you can correct me because
right now I can't come up with an example).
Imagine your environment doesn't provide any kind of multithreading
support. Couldn't you write an interactive game, a FTP server, a
messaging system? Programmers have done that for years. The fact that
you *can* write such things using multiple threads doesn't mean that't
the only way to do that, nor the best one. It's like `fork`, the Unix
programmer's hammer: every problem becomes a nail.
Also, the
scheduler runs inside a loop. How do you suppose to
run other code while the loop is executing? Remember, all
you have is a single thread. The consequence of this is
that the only way to insert something new inside a queue
is by doing it from scheduled function. Furthermore,
if scheduler is single threaded, why does is
check if the top event has changed after sleep period?
What I can agree is that python sched as it is (not
designed for multithreading) is quite useless.
The sched module (and mutex too, BTW) exists right from the beginning
of Python, ages before multithreading support were added to the
language. The algorithm hasn't changed in years; I wouldn't say it's
useless, it's just not suitable for the kind of scheduling one usually
wants to do in a multithreaded environment.
The latest release (2.6) contains this warning::
In multi-threaded environments, the scheduler class has
limitations with respect to thread-safety, inability to insert a new
task before the one currently pending in a running scheduler, and
holding up the main thread until the event queue is empty. Instead, the
preferred approach is to use the threading.Timer class instead.
--
Gabriel Genellina