This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Adding Timer to multiprocessing
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: davin, jcrotts, pitrou
Priority: normal Keywords:

Created on 2018-01-04 22:57 by jcrotts, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
Timer.py jcrotts, 2018-01-04 22:57 Example Implementation
Messages (4)
msg309487 - (view) Author: Jay Crotts (jcrotts) * Date: 2018-01-04 22:57
I wanted to propose the addition of a Timer class to the multiprocessing library similar to the one that exists in the Threading module.

Timer provides an example of how to extend the Process class that might be helpful to beginners. 

The current lack of a Timer in the multiprocessing library could encourage newer programmers to use threads where processes would be more appropriate.

In the implementation below I have added the ability to specify a # of iterations that the timed function should execute, and an additional infinite argument that would make the process execute the given function until the Timer is explicitly stopped.
msg309494 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-01-05 09:01
The threading.Timer class is in my experience little used, for two reasons:
1) it's not very flexible (no periodic calls, no restart...)
2) it's not efficient (as it creates a new thread for each timer)
3) (third optional reason) many applications needing time management actually use an event loop of some kind, as the need for time management is often coupled with the requirement to do network I/O

A hypothetical multiprocessing.Timer would have the same drawbacks as threading.Timer, the inefficiency being of course much worse.
msg309513 - (view) Author: Jay Crotts (jcrotts) * Date: 2018-01-05 17:49
I think your three reasons make sense, I've only found threading.Timer helpful in pretty trivial cases.

Do you think a more flexible or efficient Timer class would be useful?
msg312251 - (view) Author: Jay Crotts (jcrotts) * Date: 2018-02-16 20:19
Closing this issue, for the reasons Antoine outlined.
History
Date User Action Args
2022-04-11 14:58:56adminsetgithub: 76676
2018-02-16 20:19:15jcrottssetstatus: open -> closed
resolution: rejected
messages: + msg312251

stage: resolved
2018-01-05 17:49:53jcrottssetmessages: + msg309513
2018-01-05 09:01:25pitrousetmessages: + msg309494
2018-01-04 22:57:15jcrottscreate