aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-February/000295.html
diff options
context:
space:
mode:
authorneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
committerneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
commit0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch)
tree2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2001-February/000295.html
downloadnevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz
nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip
Initial commit
Diffstat (limited to '')
-rw-r--r--pipermail/nel/2001-February/000295.html68
1 files changed, 68 insertions, 0 deletions
diff --git a/pipermail/nel/2001-February/000295.html b/pipermail/nel/2001-February/000295.html
new file mode 100644
index 00000000..e4127c7d
--- /dev/null
+++ b/pipermail/nel/2001-February/000295.html
@@ -0,0 +1,68 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Nel] NeL Network Engine</TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:cblt%40cblt.org">
+ <LINK REL="Previous" HREF="000294.html">
+ <LINK REL="Next" HREF="000297.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Nel] NeL Network Engine</H1>
+ <B>Nicolas Hognon</B>
+ <A HREF="mailto:cblt%40cblt.org"
+ TITLE="[Nel] NeL Network Engine">cblt@cblt.org</A><BR>
+ <I>Wed, 28 Feb 2001 15:10:53 +0100</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="000294.html">[Nel] NeL Network Engine</A></li>
+ <LI> Next message: <A HREF="000297.html">[Nel] NeL Network Engine</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#295">[ date ]</a>
+ <a href="thread.html#295">[ thread ]</a>
+ <a href="subject.html#295">[ subject ]</a>
+ <a href="author.html#295">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>&gt;<i> Looking at Apache or Samba projects, it seems that a good compromise is to
+</I>&gt;<i> set a 'maximum client requests by thread' and spawns threads accordingly.
+</I>&gt;<i> Apache uses process forking and memory sharing, but the design remains the
+</I>&gt;<i> same. You then just tune this max_request_by_thread for each OS, say 1 for
+</I>&gt;<i> Solaris which is said thread-efficient, 10 for Linux ? Just a hint ...
+</I>
+ok this is a solution
+but as i said in my last mail the problem
+is how managing more than one socket per thread efficiently ?
+
+under windows i know other solution than select / poll but under
+unixes i don't know other solutions.
+
+some one knows other one ?
+
+--
+Nicolas Hognon
+<A HREF="mailto:nicolash@virtools.com">nicolash@virtools.com</A>
+
+Virtools - The Behavior Company
+Tel. (+33) 1 42 71 46 86 / Fax. (+33) 1 42 71 86 53
+<A HREF="http://www.virtools.com/">http://www.virtools.com/</A>
+
+
+</pre>
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="000294.html">[Nel] NeL Network Engine</A></li>
+ <LI> Next message: <A HREF="000297.html">[Nel] NeL Network Engine</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#295">[ date ]</a>
+ <a href="thread.html#295">[ thread ]</a>
+ <a href="subject.html#295">[ subject ]</a>
+ <a href="author.html#295">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>