Messages in this thread | | | Date | Fri, 26 Jun 1998 10:20:17 +1000 | From | Richard Gooch <> | Subject | Re: Thread implementations... |
| |
Stephen C. Tweedie writes: > Hi, > > On Fri, 26 Jun 1998 08:20:40 +1000, Richard Gooch > <Richard.Gooch@atnf.CSIRO.AU> said: > > >> With a fcntl(fd, F_SETSIG, signum), you can tell the kernel to send a > >> realtime signal with the specified signum instead of SIGIO for all > >> unblock events on that file descriptor. The signal will be queued with > >> the fd as an argument to the signal handler. If the signal queue > >> overflows, the kernel will deliver a generic SIGIO to let the > >> application know it should select() against all fds to find which ones > >> may have missed a realtime signal. > > > But once again we have a non-standard hack for Linux. If we do that > > then as far as I'm concerned, we may as well implement "readiness > > queues". Anyway, I'm pursuing a scalable solution that works for > > other UNIX systems. > > The only real standard interfaces under Linux are O(n) anyway. If > you're poll()ing on 10,000 socket fds, there's a limit to how fast you > can conceivably go. posix.1b signals are standard; SIGIO is standard; > combining the two is an obvious way to implement completion queues > with a minimum of non-standardness. It's not _completely_ standard, > but I don't see any fully standard and scalable interface alternatives > right now.
Combining two standard things in a non-standard way is still non-standard :-) Anyway, lets see how my threads and migrating FDs scheme scales.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |