Re: Thread implementations...
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Fri, 26 Jun 1998 10:20:17 +1000
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