Hi Dave,
----- Original Message -----
> On 07/10/2014 05:41 PM, Nathan Scott wrote:
> > Hmmm, OK. The only other suggestion then would be to make it a more
> > general, and call it "flags" (where flags can go in/out of the API).
> > But thats a pretty ordinary approach too, really.
> >
> > Oh, or could interrupted-ness be indicated via the return code?
> No, the interrupted flag is intended to be set from the calling app in
> after calling the service discovery API (via signal handler, another
> thread, or some similar means) in order to interrupt the process.
Mmm, fruity. A temporarily-replaced signal handler for the duration of
the call mighta been another alternative, allowing an interface similar
to syscall interruption (with EINTR-style return) - but, as I said...
> > Anyway, you make a decision - it seems nothing here is particularly
> > attractive, and you're in the best position to consider all of the
> > approaches - go ahead, pick one and run with it.
... so thanks for doing that :) We can always come back to timeout
handling, which it sounds like you're intending to do anyway with that
final comment of yours (below).
> OK. The latest incarnation features a pointer to a bit mask for boolean
> global options and state, including the 'interrupted' bit and now also
> the 'resolve' bit. For non-boolean global options, we're back to using a
> string argument. The name of the function is
> __pmDiscoverServicesWithOptions. I think it best describes the
> enhancement compared to the existing pmDiscoverServices(1).
Sounds good - all merged, lets get it fixed up now wrt that last bit of
QA fallout (from earlier mail, the couple of discovery failures I guess
are related to the commits discussed here).
> The commits below (brolley/dev in pcpfans) contain the changes. They
> also temporarily disable the -t or --timeout option pending a proper
> re-implementation.
OK, thanks for taking care of it. BTW, we have a release scheduled for
Wed & I'm away Thursday - if you feel it'll help, we could postpone to
Friday for that planned release? (maybe see how you're going with the
QA issues by end of your Monday & lets make a decision then if you think
a bit more time is needed). I'll be working through RHEL6 QE-reported
issues in the meantime, so hoping you can take on the other regressions
here in parallel. Thanks!!
cheers.
--
Nathan
|