> -----Original Message----- > From: Hunter, Adrian <[email protected]> > Sent: Wednesday, June 3, 2020 3:24 PM > To: Alexey Budankov <[email protected]> > Cc: Arnaldo Carvalho de Melo <[email protected]>; Jiri Olsa > <[email protected]>; Namhyung Kim <[email protected]>; Alexander > Shishkin <[email protected]>; Peter Zijlstra > <[email protected]>; Ingo Molnar <[email protected]>; Andi Kleen > <[email protected]>; linux-kernel <[email protected]> > Subject: Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled > file descriptors > > On 3/06/20 3:01 pm, Alexey Budankov wrote: > > Hi, > > > > On 03.06.2020 14:38, Adrian Hunter wrote: > >> On 1/06/20 11:05 pm, Alexey Budankov wrote: > >>> > >>> Implement adding of file descriptors by fdarray__add_stat() to > >>> fix-sized (currently 1) stat_entries array located at struct fdarray. > >>> Append added file descriptors to the array used by poll() syscall > >>> during fdarray__poll() call. Copy poll() result of the added > >>> descriptors from the array back to the storage for separate analysis. > >> > >> Why not instead call evlist__add_pollfd() before other fds are added, > >> so the fda->entries[] position is always fixed. Then this patch is not > needed. > > > > It then will block event consumption loop, at least in record mode, > > due to change sin initial assumptions behind fdarray__filter(). So > > extension of the API with 'static' fds looks safer w.r.t. possible > > functional regressions at the same time extending the API with ability > > to atomically wait for (poll()) not only event fds but also any other fds > during monitoring. > > So make fdarray__filter() return the number of filterable fds remaining. >
Or perhaps simpler, compare the return value to the number of fds that are known not to be filterable
