requests.{get,post} timeout

[Chris Angelico]

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