lkml.org 
[lkml]   [2000]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: accept() improvements for rt signals
Julian Anastasov wrote:
> But using threads I'm limited to small number of served
> clients (sockets), at least in 2.2: memory, pids. I'm talking about
> 32768+ open file descriptors with low TCP traffic.

Me, too. One thread isn't always enough; sometimes you need to pass
connections from one thread to another, e.g. on a 64 processor machine
the listening thread might pass connections to a single worker thread
on each CPU to keep the load balanced. (See http://www.kegel.com/c10k.html)

> > Also, what if there's more than one queue (e.g. a listening
> > socket with one owner/signum, and connected sockets with a
> > different owner/signum)? Which queue do you empty? Better
> > to use an atomic accept()+F_SETFAST combo that generates an
> > 'fd created' signal, then there's no need to empty any queue.
>
> Yep. I agree.

OK, cool. Don't know if we will get this race closed soon, but
it's nice that somebody else besides me now agrees it exists :-)

> Is there any expectations that si_band will be used in 2.2?

I think there's a patch you can apply. See http://people.redhat.com/zab/phhttpd/

> I know. I only asked about the rt queue limit and
> the requirement to poll after overflow. I think there is a
> limit according to the number of the async fds and the number
> of their possible events.

Good point; it would be interesting to be able to calculate
the signal queue length needed for a particular program
to prevent signal queue overflow. This would not be easy
in general, since you can get unexpected signals...

> Yep. I don't like workarounds too. So, I agree to:
>
> - setup the listener for rt signals and to duplicate its flags
> and ownership
>
> - accept() to enqueue event for connected socket
>
> - 2.2: si_band information to distinguish the events
>
> [None of the above] help to multithreaded server to redirect the
> events for the connected socket to another thread. May be a new
> accept() call? Or the listening thread have to serve these
> events before redirecting them to another thread. This event
> can occur with very fast network and very slow CPU :)

I think we're on the same wavelength. Don't know how many
of these API rough edges can be smoothed over in the 2.3
kernel before 2.4 is released, but it'd be nice to have
(a) agreement that rough edges in the sigio api
makes writing sigio-based servers hard at the moment in 2.3,
and (b) a plan for smoothing out the rough edges.
- Dan

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

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.134 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site