On 08.06.2020 19:07, Jiri Olsa wrote: > On Mon, Jun 08, 2020 at 12:54:31PM +0300, 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: <SNIP> >>>>> 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); > > I think there's solution without having filterable type, > I'm not sure why you think this is needed > > I'm busy with other things this week, but I think I can > come up with some patch early next week if needed
Friendly reminder. Thanks, Alexey
