lkml.org 
[lkml]   [1998]   [Jun]   [25]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateFri, 26 Jun 1998 10:20:17 +1000
FromRichard Gooch <>
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.424 / U:0.230 seconds]
©2003-2008 Jasper Spaans