Re: > 15,000 Simultaneous Connections

Stephen C. Tweedie (sct@redhat.com)
Wed, 15 Sep 1999 00:54:42 +0100 (BST)


Hi,

On Mon, 6 Sep 1999 13:29:55 -0400 (EDT), Chuck Lever <cel@monkey.org>
said:

> On Mon, 6 Sep 1999, Mike Jagdis wrote:

>> Partly. But you want to ask for a real time signal to be used
>> so that you get the fd as well. Then there's a limit on the
>> number of signals that can be queued at once and, I think, if
>> you hit the limit signals get dropped (or turned into non-queuing
>> SIGINFO) which can be a problem.

The current code in the kernel delivers a normal, unqueued SIGIO
specifically to notify the application of overflow.

>> Plus sharing the signal queue between tasks/{processes,threads} isn't
>> possible.

In POSIX, it is. The lack of kernel support for shared signal queues is
an entirely orthogonal problem!

>> And if you are delivering to a process group each process gets its
>> own siginfo allocated and queued. Then there's all the signal code
>> adding to the overhead on each event.

There is no signal delivery involved at all. You just use sigwaitinfo()
to pull the next event off the queue. The signal should remain blocked
at all times if you are interested in performance.

> i have to agree with all of this -- using queued signals is not a win
> in terms of application complexity. add to this that the C library
> will want to use signals for its own purposes, and there is no
> standard way for an application to discover what signals are already
> in use.

The C library never, ever uses queued signals for its own purposes.

> gaurav banga and jeff mogul presented a paper at the june usenix technical
> conference which describes a new kernel API for scalably managing I/O
> events. the link:

> http://www.cs.rice.edu/~gaurav/papers/usenix99.ps

This API is almost identical to the queued signal model with
sigwaitinfo(), except that it cannot give you multiple queues. In other
words, it is a subset of what the signal model gives you.

--Stephen

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