On 15.06.2020 15:30, Jiri Olsa wrote: > On Mon, Jun 15, 2020 at 08:20:38AM +0300, Alexey Budankov wrote: >> >> 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. > > hm? I believe we discussed this in here: > https://lore.kernel.org/lkml/20200609145611.GI1558310@krava/
Do you want it to be implemented like in the patch posted by the link? ~Alexey > > jirka >
