Multi-threading with a simple timer?
rosuav at gmail.com
Tue Jul 3 11:21:03 EDT 2018
On Wed, Jul 4, 2018 at 12:05 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Gregory Ewing <greg.ewing at canterbury.ac.nz>:
>> Robin Becker wrote:
>>> if I leave out the signal.signal(signal.SIGALRM,signal.SIG_IGN) then
>>> the timeout function gets called anyway.
>> Yes, it needs some more stuff around it to make it useful. Probably
>> you also want the signal handler to raise an exception and catch it
>> somewhere rather than exiting the process.
> My advice: stay away from (non-terminal) signals. They are a primitive
> communication scheme that *might* have had uses in the early 1970's.
> At the time signals were part of so-called "asynchronous programming."
> The pattern called for the main routine to have:
> for (;;)
> and *everything* in the program was done in signal handlers.
> Unless you do *everything* in signal handlers, you should do *nothing*
> in signal handlers.
Yeah, signal handlers are utterly useless. You never want to use them
to receive messages from the operating system in a process-independent
way. The fact that it's possible to use them badly means that we
should abolish them completely and never use them, like ever. It's not
like they're a really effective way for you to be notified that you no
longer have a controlling terminal, thus permitting you to decide
whether to continue or terminate. It's not like they're a standard way
for the user to say "please interrupt this operation", thus allowing
you to cleanly break off what you're doing and return to the main
loop. No, signal handlers are utterly useless, and only MIGHT have had
uses forty years ago. They're completely and utterly outmoded by
modern systems that use HTTP and XML to send easy-to-use messages
More information about the Python-list