pcp
[Top] [All Lists]

Re: pmServiceDiscoveryInterrupt() commit a8b87e2 et al.

To: Dave Brolley <brolley@xxxxxxxxxx>
Subject: Re: pmServiceDiscoveryInterrupt() commit a8b87e2 et al.
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Wed, 09 Jul 2014 11:17:20 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53BC0D60.4000007@xxxxxxxxxx> (Dave Brolley's message of "Tue, 08 Jul 2014 11:25:20 -0400")
References: <20140619194444.3B03D58015@xxxxxxxx> <53AB0F27.602@xxxxxxxxxx> <1063089485.33910956.1403758262805.JavaMail.zimbra@xxxxxxxxxx> <53AC35B8.3000802@xxxxxxxxxx> <1193390011.34470957.1403829231937.JavaMail.zimbra@xxxxxxxxxx> <1374649635.181830.1404090114319.JavaMail.zimbra@xxxxxxxxxx> <53BC0D60.4000007@xxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
brolley wrote:

Regarding commit 9021460e, which nathans already reviewed(?) / merged:

>   Implement overall timeout for service discovery.
>   
>   -t=N.N, --timeout=N.N for pmfind. N.N is the timeout period
>   in seconds.

I have one concern: the new timeout parameter passed to the
pmDiscover* function doesn't actually work!  What i mean is that it is
not sufficient to perform the timeout functionality by itself: it only
sets up a posix timer to send a SIGALARM sometime.  It does not
consume that signal, but requires the client to register a SIGALRM
handler, and let it flip the options->interrupt flag.  This embryonic
a service the pmfind app could have done for itself, by just calling
alarm(2)/setitimer(2).

A better approach would be to avoid presuming anything about the
signal handling state of the enveloping application (and thus not use
SIGALRM-generating facilities).  For example, libpcp could spawn an
internal thread that just sleeps awhile, then sets the currently
operating context/interrupt flag.  (The code would have to be careful
about races between that thread's activities vs. lifecycle, but it
doesn't sound too bad.)


- FChE

<Prev in Thread] Current Thread [Next in Thread>