Davide Libenzi a écrit :
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 my particular epoll application, the producer is tcp stack, and I have one
consumer. If an network event is lost in the EFAULT handling, its lost
forever. In any case, my application do provide a correct user area, so this
problem is only theorical.
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.
Please dont slow the hot path for a basically "User Error". It's already
tested in the transfert function, with two conditional branches for each
transfered event.
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.
Yes, but this particular patch was a followup on own kevent Andrew patch.
I have a bunch of patches for epoll I will send to you :)
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[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]
