linux-kernel - RE: epoll,threading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 26 May 2007 16:01:36 -0700
From:	"David Schwartz" <davids@...master.com>
To:	<linux-kernel@...r.kernel.org>
Subject: RE: epoll,threading

> Hello all,
>
> I want to know in detail about , what the events (epoll or /dev/poll or
> select ) achieve in contrast to  thread per client.
>
> i can have a thread per client and use send and recv system call directly
> right? Why do i go for these event mechanisms?
>
> Please help me to understand this.

Aside from the obvious, consider a server that needs to do a little bit of
work on each of 1,000 clients on a single CPU system. With a
thread-per-client approach, 1,000 context switches will be needed. With an
epoll thread pool approach, none are needed and five or six are typical.

Both get you the major advantages of threading. You can take full advantage
of multiple CPUs. You can write code that blocks occasionally without
bringing the whole server down. A page fault doesn't stall your whole
server.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/