requests.{get,post} timeout
Chris Angelico
rosuav at gmail.com
Thu Aug 24 15:15:38 EDT 2017
On Fri, Aug 25, 2017 at 5:07 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> On Fri, Aug 25, 2017 at 3:40 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> Signals are an arcane Unix communication method. I strongly recommend
>>> against using signals for anything but terminating a process, and even
>>> then you have to be extra careful.
>>>
>>> I have seen code that uses signals for runtime communication, but none
>>> of it was free from race conditions.
>>
>> Strongly disagree. Signals exist so that they can be used. Sending
>> SIGHUP to a daemon to tell it to reload its configs is well-supported
>> by the ecosystem;
>
> The ancient SIGHUP reload antipattern is infamous:
>
> /bin/kill -HUP $MAINPID
>
> Note however that reloading a daemon by sending a signal (as with the
> example line above) is usually not a good choice, because this is an
> asynchronous operation and hence not suitable to order reloads of
> multiple services against each other. It is strongly recommended to
> set ExecReload= to a command that not only triggers a configuration
> reload of the daemon, but also synchronously waits for it to
> complete.
>
> <URL: https://www.freedesktop.org/software/systemd/man/systemd.servic
> e.html>
>
> The SIGHUP practice makes automation painful. I want to reconfigure but
> can't be sure when the new configuration has taken effect.
And yet, despite you calling it an antipattern, it's still very well
supported. There are limitations to it - as you say, it's asynchronous
- but it is the default for many services. SystemD is completely
supporting it.
ChrisA
More information about the Python-list
mailing list