On Mon, Jun 22, 2020 at 12:47:19PM +0300, Alexey Budankov wrote: SNIP
> >>>>>> 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? > > > > no idea.. looking for good solution ;-) > > > > how about switching completely to epoll? I tried and it > > does not look that bad > > Well, epoll() is perhaps possible but why does it want switching to epoll()? > What are the benefits and/or specific task being solved by this switch? epoll change fixes the same issues as the patch you took in v8 on top of it it's not a hack and wil make polling more user friendly because of the clear interface > > > > > there might be some loose ends (interface change), but > > I think this would solve our problems with fdarray > > Your first patch accomodated in v8 actually avoids fds typing > and solves pos (=fdarray__add()) staleness issue with fdarray. yea, it was a change meant for discussion (which never happened), and I considered it to be more a hack than a solution I suppose we can live with that for a while, but I'd like to have clean solution for polling as well jirka
