[issue33590] sched.enter priority has no impact on execution

[Matthew Fisher]

Matthew Fisher  added the comment:

> I did look at the code :-)

I also looked at the code.  I had to do so to understand why the example output 
was not "as expected."  ;)

> I don't agree about the example in the documentation, it is a clear
> demonstration about how to use the API in general and AFAIK is not
> intended to show how priorities work.

Although I came to the same conclusion as you regarding both the fact and the 
reason the output was correct, I respectfully disagree that the example is 
clear.  It is not.  Yes, the example, as written, is intended to demonstrate 
the API -- which consists of several functionalities *including priority*.  If 
this were not so, the example would not be passing different priority values 
with the same delay value.

I suggest re-opening this issue as a documentation bug and modifying the 
example to use enterabs instead of enter.

Respectfully,
M Fisher

--
nosy: +mfisher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33590] sched.enter priority has no impact on execution

[Raymond Hettinger]

Raymond Hettinger  added the comment:

It would be nice to either modify the example or add another example to show 
the use of enterabs() and of the priority field being used as a tie breaker for 
two events scheduled at the same time.

--
nosy: +rhettinger
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33590] sched.enter priority has no impact on execution

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I did look at the code :-)

The enter() method just calls enterabs() with an absolute time calculated from 
the current time (using the timefunc for the scheduler) and the passed relative 
time.  Two calls of enter() with the same relative time will therefore use 
different absolute times unless you're using custom time function with a lower 
resolution. 

Prorities are only used when who events are scheduled for the same absolute 
time, which is easy to arrange for using enterabs() but less so using enter() 
but still can happen when using calculated timeout values.

I don't agree about the example in the documentation, it is a clear 
demonstration about how to use the API in general and AFAIK is not intended to 
show how priorities work.

--
resolution:  -> not a bug
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33590] sched.enter priority has no impact on execution

[R. David Murray]

R. David Murray  added the comment:

I think Ronald is correct.

The priority argument for enter would apply if you called enter twice with two 
different delays, but they happen to end up pointing to the same moment in time 
from the scheduler's point of view.

How would the computer know that two calls to enter with the same delay are 
supposed to point to the same moment in time?

But you are correct, it looks like the example would make more sense if it used 
enterabs, not enter.

You can test our theory by writing time and delay functions with a course 
enough resolution that two sequential calls to delay will end up pointing to 
the time time unit.  (Or we could look at the code :)

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33590] sched.enter priority has no impact on execution

[sahilmn]

sahilmn  added the comment:

The task schedule is executed when `s.run()` is called. There should be a
*delay = 5*  from the time the scheduling statement is executed.

If your claim is true, the priority argument is useless since it has no
impact on the execution order when `delay` values are equal. Clearly, this
is not the case since the example for `enter` at
https://docs.python.org/3/library/sched.html aims to demonstrate the use of
`priority` argument.

On Mon, May 21, 2018 at 4:14 AM, Ronald Oussoren 
wrote:

>
> Ronald Oussoren  added the comment:
>
> I don't think  there's a bug here: sched.enter schedules an event some
> time after the current time. The two calls to sched.enter are not at the
> same time, hence the priority is not used because the events are scheduled
> at different times.
>
> --
> nosy: +ronaldoussoren
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33590] sched.enter priority has no impact on execution

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I don't think  there's a bug here: sched.enter schedules an event some time 
after the current time. The two calls to sched.enter are not at the same time, 
hence the priority is not used because the events are scheduled at different 
times.

--
nosy: +ronaldoussoren

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33590] sched.enter priority has no impact on execution

[sahilmn]

New submission from sahilmn :

`sched.enter` doesn't work as expected. If two events are scheduled with the 
same delay, then their order of execution seems to be dictated by the order of 
`enter` statements for the events instead of the priority order.

Ref attached file with example code. `sched.enterabs` works as expected.

--
files: sched.enter.bug.py
messages: 317215
nosy: sahilmn
priority: normal
severity: normal
status: open
title: sched.enter priority has no impact on execution
versions: Python 3.6
Added file: https://bugs.python.org/file47609/sched.enter.bug.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com