requests.{get,post} timeout

[Marko Rauhamaa]

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.

> use of SIGCHLD and SIGWINCH for non-termination conditions is also
> vital. How else should an operating system or desktop environment
> inform a process of something important?

I never use SIGCHLD. Instead I leave a pipe open between the child and
the parent and notice an EOF on the pipe as the child exits. The pipe
(or socketpair) is handy for other IPC as well.

The signalfd mechanism in newer Linux kernels might make signals
borderline usable. However, code that relies on signals had better
meticulously call sigprocmask(2) and understand the precise points where
signals should be let through.

Another thing: this is a C programming issue, but functions like
fprintf() should never be used together with signals:

   <URL: http://unix.derkeiler.com/Newsgroups/comp.unix.programmer/200
   6-05/msg00356.html>


Marko