On 08.06.2020 12:54, Alexey Budankov wrote: > > On 08.06.2020 11:43, Jiri Olsa wrote: >> On Mon, Jun 08, 2020 at 11:08:56AM +0300, Alexey Budankov wrote: >>> >>> On 05.06.2020 19:15, Alexey Budankov wrote: >>>> >>>> On 05.06.2020 14:38, Jiri Olsa wrote: >>>>> On Fri, Jun 05, 2020 at 12:50:54PM +0200, Jiri Olsa wrote: >>>>>> On Wed, Jun 03, 2020 at 06:52:59PM +0300, 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 analysis. >>>>>>> >>>>>>> Signed-off-by: Alexey Budankov <alexey.budan...@linux.intel.com> >>>>>>> --- <SNIP> >>>>>>> + fda->stat_entries[i].events); >>>>>> >>>>>> so every call to fdarray__poll will add whatever is >>>>>> in stat_entries to entries? how is it removed? >>>>>> >>>>>> I think you should either follow what Adrian said >>>>>> and put 'static' descriptors early and check for >>>>>> filter number to match it as an 'quick fix' >>>>>> >>>>>> or we should fix it for real and make it generic >>>>>> >>>>>> so currently the interface is like this: >>>>>> >>>>>> pos1 = fdarray__add(a, fd1 ... ); >>>>>> pos2 = fdarray__add(a, fd2 ... ); >>>>>> pos3 = fdarray__add(a, fd2 ... ); >>>>>> >>>>>> fdarray__poll(a); >>>>>> >>>>>> num = fdarray__filter(a, revents, destructor, arg); >>>>>> >>>>>> when fdarray__filter removes some of the fds the 'pos1,pos2,pos3' >>>>>> indexes are not relevant anymore >>>> >>>> and that is why the return value of fdarray__add() should be converted >>>> to bool (added/not added). Currently the return value is used as bool >>>> only allover the calling code. >>>> >>>> fdarray__add_fixed() brings the notion of fd with fixed pos which is >>>> valid after fdarray__add_fixed() call so the pos could be used to access >>>> pos fd poll status after poll() call. >>>> >>>> pos = fdarray__add_fixed(array, fd); >>>> fdarray_poll(array); >>>> revents = fdarray_fixed_revents(array, pos); >>>> fdarray__del(array, pos); >>> >>> So how is it about just adding _revents() and _del() for fixed fds with >>> correction of retval to bool for fdarray__add()? >> >> I don't like the separation for fixed and non-fixed fds, >> why can't we make generic? > > Usage models are different but they want still to be parts of the same class > for atomic poll(). The distinction is filterable vs. not filterable. > The distinction should be somehow provided in API. Options are: > 1. expose separate API calls like __add_nonfilterable(), > __del_nonfilterable(); > use nonfilterable quality in __filter() and __poll() and, perhaps, other > internals; > 2. extend fdarray__add(, nonfilterable) with the nonfilterable quality > use the type in __filter() and __poll() and, perhaps, other internals; > expose less API calls in comparison with option 1 > > Exposure of pos for filterable fds should be converted to bool since currently > the returned pos can become stale and there is no way in API to check its > state. > So it could look like this: > > fdkey = fdarray__add(array, fd, events, type) > type: filterable, nonfilterable, somthing else > revents = fdarray__get_revents(fdkey); > fdarray__del(array, fdkey);
Are there any thoughts regarding this? ~Alexey
