Messages in this thread | | | Date | Mon, 6 Sep 1999 15:37:21 +0100 (GMT/BST) | From | Mike Jagdis <> | Subject | Re: > 15,000 Simultaneous Connections |
| |
On 6 Sep 1999, Andreas Schwab wrote:
> Mike Jagdis <mike@roan.co.uk> writes: > > |> The main cost of select and poll, on the kernel side, is scanning > |> the fds to see what is ready. The way select and poll are usually > |> used we want a means to express an interest in an fd and then > |> receive a stream of "events" as fds change state. > > That's what SIGIO is for.
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. Plus sharing the signal queue between tasks/{processes,threads} isn't possible. 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. Yup, signals are an option, but they have their own set of gotchas and scalability issues which are probably even less well understood than select and poll :-).
Mike
-- A train stops at a train station, a bus stops at a bus station. On my desk I have a work station... .----------------------------------------------------------------------. | Mike Jagdis | Internet: mailto:mike@roan.co.uk | | Roan Technology Ltd. | | | 2 Markham Mews, Broad Street | Telephone: +44 118 989 0403 | | Wokingham ENGLAND | Fax: +44 118 989 1195 | `----------------------------------------------------------------------'
- 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/
| |