On Thu, Jan 22, 2015 at 01:53:35AM -0500, Vince Weaver wrote: > On Wed, 21 Jan 2015, Jiri Olsa wrote: > > > > However if we revert this code, we'll loose nice (and standard) way > > to check if the event is still valid.. not sure how to handle this. > > there's likely no need to revert as my code wasn't really released and > I've already fixed it to work with the new interface. > > I was mostly asking just so I could update the manpage to explain the new > behavior, as tools that expect to be backwards compatible will have to > handle both ways of detecting a process dieing. > > > > Part of why my code doesn't just exit on POLLHUP is because you can > > > get that result for reasons other than a process exit (for example, > > > if you are using ioctl(PERF_EVENT_IOC_REFRESH) > > > > Nope, this is related to POOL_HUP (notice the '_') which you'll get > > accompanied with SIGIO if you setup this. > > So what happens if you are using a signal handler to monitor a child and > the child exits?
AFAICS wrt to SIGIO, we notify only with POLL_IN if there's new data and POLL_HUP if we reached the event_limit - the one you set with PERF_EVENT_IOC_REFRESH ioctl > > It's a shame the poll and signal handler interfaces are subtly different, > though I guess some of that is probably due to historical reasons. I've actually never used the SIGIO interface in perf other than when I was checking your gi repo with test code ;-) so I'm not sure what the correct behaviour should be when monitored process dies.. I'd say we should send SIGIO with POLL_HUP, but that clashes with that 'event_limit' thing.. I'll check on that thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
