On Thu, 9 Nov 2006, Eric Dumazet wrote:
> Davide Libenzi a �crit :
> >
> > I don't care about both ways, but sys_poll() does the same thing epoll does
> > right now, so I would not change epoll behaviour.
> >
>
> Sure poll() cannot return a partial count, since its return value is :
>
> On success, a positive number is returned, where the number returned is
> the number of structures which have non-zero revents fields (in other
> words, those descriptors with events or errors reported).
>
> poll() is non destructive (it doesnt change any state into kernel). Returning
> EFAULT in case of an error in the very last bit of user area is mandatory.
>
> On the contrary :
>
> epoll_wait() does return a count of transfered events, and update some state
> in kernel (it consume Edge Trigered events : They can be lost forever if not
> reported to user)
>
> So epoll_wait() is much more like read(), that also updates file state in
> kernel (current file position)
Lost forever means? If there are more processes watching some fd
(external events), they all get their own copy of the events in their own
private epoll fd. It's not that we "steal" things out of the kernel, is
not a 1:1 producer/consumer thing (one producer, 1 queue). It's one
producer, broadcast to all listeners (consumers) thing. The only case
where it'd matter is in the case of multiple threads sharing the same
epoll fd.
In general, I'd be more for having the userspace get his own SEGFAULT
instead of letting it go with broken parameters. If I'm coding userspace,
and I'm doing something wrong, I like the kernel to let me know, instead
of trying to fix things for me.
Also, epoll can easily be fixed (add a param to ep_reinject_items() to
re-inject items in case of error/EFAULT) to leave events in the ready-list
and let the EFAULT emerge.
Anyone else has opinions about this?
PS: Next time it'd be great if you Cc: me when posting epoll patches, so
you avoid Andrew the job of doing it.
- Davide
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
