> > 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/