Messages in this thread | | | Date | Mon, 13 Sep 1999 02:31:17 +0000 | From | Steve Underwood <> | Subject | Re: POSIX aio vs completion ports |
| |
Alan Cox wrote:
> > no, it isn't a non-kernel issue. this must be done atomically wrt the > > user level, so it must be done in the kernel. there's no good way for the > > No. > > > application (or library) to allocate a specific RT signal, so there must > > be some form of "gentlemen's agreement" between libraries and application > > as to which uses which signal. > > Yes. Thats not hard > > > alan, you can detect an overflow, but recovering from one is another > > matter. > > poll()
Well, that brings the discussion full circle. It started with the performance limitations of poll() with lots of fds, and now poll() is presented as a solution to a solution. There's a hole in my bucket, dear Lisa, dear Lisa.....
Completion ports have one substantial benefit over the POSIX RT signal queues - they will never overflow. Messy, and ultimately somewhat futile, schemes for recovering from overflows are unnecessary. It seems to me that any recovery is going to be slow, and maybe a little unpredictable. This will be happening at a very busy time (otherwise there wouldn't have been an overflow), so clumsy recoveries just won't cut it.
With completion ports there is one port per monitored feature, so they can't overflow. I really don't like the completion port scheme, though. It feels very "heavyweight" in use, and from my (admittedly somewhat limited) experience of using them with NT they didn't seem to be very hot performers. I think there have been much better suggestions on this list.
Steve
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |