> -----Original Message----- > From: Hunter, Adrian <adrian.hun...@intel.com> > Sent: Wednesday, June 3, 2020 3:24 PM > To: Alexey Budankov <alexey.budan...@linux.intel.com> > Cc: Arnaldo Carvalho de Melo <a...@kernel.org>; Jiri Olsa > <jo...@redhat.com>; Namhyung Kim <namhy...@kernel.org>; Alexander > Shishkin <alexander.shish...@linux.intel.com>; Peter Zijlstra > <pet...@infradead.org>; Ingo Molnar <mi...@redhat.com>; Andi Kleen > <a...@linux.intel.com>; linux-kernel <linux-kernel@vger.kernel.org> > 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
