better scheduler with correct sleep times

[Gabriel Genellina]

On 2008-10-21, sokol <tvrtko.sokolovski at gmail.com> wrote:
> On Oct 21, 2:19 am, greg <g... at cosc.canterbury.ac.nz> wrote:
>> 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