Messages in this thread |  | | Date | Mon, 24 Sep 2001 15:30:17 -0700 (PDT) | From | Davide Libenzi <> | Subject | Re: [PATCH] /dev/epoll update ... |
| |
On 24-Sep-2001 Jamie Lokier wrote: > Davide Libenzi wrote: >> Sure you can avoid the scan, if you pick up one event at a time. To >> be compared to /dev/epoll you need the signal-per-fd patch plus a >> method to collect the whole event-set in a single system call ( see >> perfs ). > > Yes, I agree. A variant of sigwaitinfo that will return multiple queued > signals was mentioned ages ago, but because the siginfo structure is > much larger than is needed, that isn't a very effective use of cache. > > Something specialised for fd events is more appropriate IMO. Large > numbers of queued RT signals aren't used for anything else AFAIK anyway, > not even timers.
The bottom line is, for what i saw in my tests, that both /dev/epoll and RT signals ( with signal-per-fd ) offers good performance and scalability.
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |