From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2001-February/000294.html | 62 +++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 pipermail/nel/2001-February/000294.html (limited to 'pipermail/nel/2001-February/000294.html') diff --git a/pipermail/nel/2001-February/000294.html b/pipermail/nel/2001-February/000294.html new file mode 100644 index 00000000..5bb46c8b --- /dev/null +++ b/pipermail/nel/2001-February/000294.html @@ -0,0 +1,62 @@ + + + + [Nel] NeL Network Engine + + + + + + +

[Nel] NeL Network Engine

+ Vincent Caron + v.caron@zerodeux.net
+ Wed, 28 Feb 2001 15:30:32 +0100 +

+
+ +
Vianney Lecroart wrote:
+> 
+> What we don't know is the thread number limit after what the system uses too
+> much CPU. In the linuxthread faq, they
+> said that an application should not create more than 100 thread. In this
+> case, we have to forget the solution where each
+> socket is on a thread and use a blocked receive(). The problem is that
+> select() is quite slow and if we have only 100 thread,
+> each thread needs to manage, with a select(), around 50 players and we ll
+> lost lot of time to create the array for the select()
+> and check who have wakeup the select().
+
+Looking at Apache or Samba projects, it seems that a good compromise is to
+set a 'maximum client requests by thread' and spawns threads accordingly.
+Apache uses process forking and memory sharing, but the design remains the
+same. You then just tune this max_request_by_thread for each OS, say 1 for
+Solaris which is said thread-efficient, 10 for Linux ? Just a hint ...
+
+
+ + + +
+

+ -- cgit v1.2.1