Add restart of poll in read_tmo

[hermunn]

Add check for negative return value from poll in read_tmo. A negative
return value can happen if a signal interupts poll(), and then the
correct behavior is to call poll() again.

[bsdphk]

So my worry about this is if we get into a unkillable process situation.

Have you pondered/looked at that ?

[hermunn]

I did not like that a signal would send us straight into a read that may or may not block (depending on the fd), and this seems to be undesired, as we can lose the timeout behavior. But, as you say, restarting the poll might pose other problems. I need to have a closer look at the callers of read_tmo.

[hermunn]

The read_tmo seems to only be called from VCLI_ReadResult, but the latter can be called both on a (nonblocking) TCP socket (in varnishadm), or on a pipe between the manager and worker process.

When read_tmo returns before getting the full reply, VCLI_ReadResult will return CLIS_COMMS. If VCLI_ReadResult was called from mgt_cli.c, then the manager process will terminate the worker process, while varnishadm will simply give up.

If we change continue; to break;, we will not run into the potentially blocking read, but return immediately.

@bsdphk, would you prefer a break; instead of continue;?

[hermunn]

Backport review: bsdphk's fix backported to 4.1 as c330106.