Why is there no Timer class in the Python multiprocessing module?

Question

Thus, the threading module has the Timer class, which is part of the Thread class, for repeatedly performing certain tasks.

I was wondering why the multiprocessor module does not have something similar to the similar TimedProcess class, for example, which does not exist from Process for repeatedly performing some tasks?

You can write such a synchronized process, and I wrote one, but still curious. Or am I missing something?

Answer 1

This is pretty simple to implement:

 from multiprocessing import Process, Event class Timer(Process): def __init__(self, interval, function, args=[], kwargs={}): super(Timer, self).__init__() self.interval = interval self.function = function self.args = args self.kwargs = kwargs self.finished = Event() def cancel(self): """Stop the timer if it hasn't finished yet""" self.finished.set() def run(self): self.finished.wait(self.interval) if not self.finished.is_set(): self.function(*self.args, **self.kwargs) self.finished.set() 

I am not sure why there is not one in stdlib. Perhaps because it is less likely to be useful?

Answer 2

This is a fairly open-ended question, and a literal answer will not be very helpful.

But let's try to come up with some reasonable guesses.

pyprocessing * was not. Why not? Probably because it is not particularly useful.

Almost any non-trivial application that needs timers needs several timers, repeating timers, relatively fast timers, etc. Disabling a new thread for each timing event is a terrible idea.

So why is this even in threading ?

Well, for trivial applications this can be useful. It is not unreasonable to add threading to a single-processor application so that you can start Timer to signal the main thread and interrupt it if it is lost, for example. But this does not apply to multiprocessing .

In addition, threading is one of those modules that are intended to be used as example code, and not just as libraries, and this is especially true when it was first added. Therefore, docs refers to the source . And Timer is a great example of sample code, it’s obvious in what it does and how it works, and it's hard to think of something much simpler to demonstrate how to use the synchronization object. But you do not need code in two places to serve as an example, and there is nothing extra and multiprocessing to demonstrate.

And finally, Itamar Stull-Trauring wanted this, did the work and offered it, and no one had any arguments against its inclusion; supposedly the same never happened with pyprocessing . **

During planning 2.6 / 3.0, PEP 371 adapted pyprocessing to the stdlib multiprocessing module. It was quite a lot of work, and it was done in a hurry, especially since they took on the task of PEP8-formatting names in threading , so they would not have to rename all pyprocessing standard names in threading just so that someone renamed them again when threading was fixed a year or two later. Thus, although the possibility of replacing threading was one of the secondary goals, if possible, I assume that no one did a full survey to make sure that this was done.

Since then, apparently, no one has noticed that he went missing and suggested it, or no one made sufficiently convincing arguments, or no one did the actual work. If you think this should be added, and you can protect your faith, create a mistake or write python ideas, and also include your implementation and sign a PSF sponsorship agreement, and it can perpetuate you. :)

_{* Unfortunately, I cannot find any good historical links to pyprocessing . The original repo is dead, members are moving towards maintaining the stdlib multiprocessing and backpack module}

multiprocessing , even if this project was largely supplanted by billiard , and over the years, a new and unrelated project took its original name ...

_{** Note that in issue # 428326 , where Timer was first proposed, more than half of the argument is that this is a good example code.}