aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-February/000278.html
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--pipermail/nel/2001-February/000278.html73
1 files changed, 73 insertions, 0 deletions
diff --git a/pipermail/nel/2001-February/000278.html b/pipermail/nel/2001-February/000278.html
new file mode 100644
index 00000000..551c2232
--- /dev/null
+++ b/pipermail/nel/2001-February/000278.html
@@ -0,0 +1,73 @@
+<!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:v.caron%40zerodeux.net">
+ <LINK REL="Previous" HREF="000272.html">
+ <LINK REL="Next" HREF="000279.html">
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Nel] NeL Network Engine</H1>
+ <B>Vincent Caron</B>
+ <A HREF="mailto:v.caron%40zerodeux.net"
+ TITLE="[Nel] NeL Network Engine">v.caron@zerodeux.net</A><BR>
+ <I>Mon, 26 Feb 2001 19:50:35 +0100</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="000272.html">[Nel] NeL Network Engine</A></li>
+ <LI> Next message: <A HREF="000279.html">Re[2]: [Nel] NeL Network Engine</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#278">[ date ]</a>
+ <a href="thread.html#278">[ thread ]</a>
+ <a href="subject.html#278">[ subject ]</a>
+ <a href="author.html#278">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>Bernard Hugueney wrote:
+&gt;<i>
+</I>&gt;<i> Well, I'm as far as possible from a threads expert, but I think that
+</I>&gt;<i> what makes LinuxThreads special is that they are system threads (vs user
+</I>&gt;<i> threads) maybe heavier, but making use of SMP, so basically, I think
+</I>&gt;<i> the max nb of threads is very much system dependand (SMP?).
+</I>
+Threads are indeed system tasks internaly, and they are scheduled as such.
+The number of tasks and/or threads is only limited by NR_TASKS at compile
+time in Linux. And yes, the scheduler is not really effective at managing
+more than 1000~2000 tasks, and doesn't provide enough semantics to
+optimize thread use. This is rather a matter of design, and you could
+without great trouble design a Linux scheduler that handles a bunch of
+threads the way you expect it, but as far as I known, only the real time
+versions of Linux (such as RTlinux) have played with this part of the
+Linux code. Now about SMP, Linux does spreads threads over the available
+CPUs to optimize parallelism, but there's no limitation. And you'll only
+get a speed up on SMP machines if you really have parallel threads (ie.
+not a thread join every 10 lines !).
+
+I guess we're raising the question of time sharing (or 'multiplexing', sounds
+cool :)). You can let the OS do it for you and use threads everywhere : BeOS
+is a good example since everything than can receive events is in a thread.
+You can do it all by yourself : use one process and dispatch the incoming
+events to functions (ie. WinProc). Why you would use one more than the other
+is a matter of design, and also depends on the type of application and the
+OS you use. The anwser is really not simple and won't certainly fit in a mail,
+but I must admit I don't have good pointers to give ...
+
+</pre>
+
+
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="000272.html">[Nel] NeL Network Engine</A></li>
+ <LI> Next message: <A HREF="000279.html">Re[2]: [Nel] NeL Network Engine</A></li>
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#278">[ date ]</a>
+ <a href="thread.html#278">[ thread ]</a>
+ <a href="subject.html#278">[ subject ]</a>
+ <a href="author.html#278">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>