Re: better scheduler with correct sleep times

[greg]

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".

--
Greg

[sokol]

On Oct 21, 2:19*am, greg <[e-mail] erbury.ac.nzwro te:

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). 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.

--
Tvrtko

[Carl Banks]

On Oct 21, 4:58*am, sokol <tvrtko.sokolov [e-mail] ote:

On Oct 21, 2:19*am, greg <[e-mail] erbury.ac.nzwro te:

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). 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.

Yeah, that does happen.

I often used this sort of thing (pre-Python days, so a long time ago)
in single-threaded, real-time simulations.

Don't know mcuh about the sched module, but time scheduling in general
doesn't need multithreading, not one bit.
Carl Banks

[greg]

sokol wrote:

Also, the
scheduler runs inside a loop. How do you suppose to
run other code while the loop is executing?

The sleep function could be doing a select with a
timeout on some other source of events, such as a
socket or a gui input event stream. One possible
response to such an event is to schedule another
event. There's not so much need for that nowadays,
since most gui libraries provide a way of scheduling
timed events as part of their built-in event loop,
but you might want to use something like this in
a server that deals with network connections.

Another possible use is discrete-event simulation,
where the "sleep" function doesn't physically sleep
but just advances a simulated time, and all events
(other than the first one that starts everything off)
are scheduled by callbacks for other events.

So while its uses are rather specialized, I wouldn't
say it's useless. The main problem is that its nature
needs to be much more clearly spelled out in the
docs -- it's something of an attractive nuisance the
way it is.

--
Greg

[Gabriel Genellina]

On 2008-10-21, sokol <tv************ ***@gmail.comwr ote:

On Oct 21, 2:19*am, greg <[e-mail] erbury.ac.nzwro te:

>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

[sokol]

On Oct 22, 2:28*am, greg <[e-mail] erbury.ac.nzwro te:

sokol wrote:

Also, the
scheduler runs inside a loop. How do you suppose to
run other code while the loop is executing?

The sleep function could be doing a select with a
timeout on some other source of events, such as a
socket or a gui input event stream. One possible
response to such an event is to schedule another
event. There's not so much need for that nowadays,
since most gui libraries provide a way of scheduling
timed events as part of their built-in event loop,
but you might want to use something like this in
a server that deals with network connections.

Another possible use is discrete-event simulation,
where the "sleep" function doesn't physically sleep
but just advances a simulated time, and all events
(other than the first one that starts everything off)
are scheduled by callbacks for other events.

So while its uses are rather specialized, I wouldn't
say it's useless. The main problem is that its nature
needs to be much more clearly spelled out in the
docs -- it's something of an attractive nuisance the
way it is.

--
Greg

I see. The delayfunc is user defined function so it
doesn't have to sleep at all. If you are creative
enough, you can use this scheduler in many ways.

--
Tvrtko