diff options
| author | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
|---|---|---|
| committer | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
| commit | 0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch) | |
| tree | 2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2001-February/000278.html | |
| download | nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip | |
Initial commit
Diffstat (limited to '')
| -rw-r--r-- | pipermail/nel/2001-February/000278.html | 73 |
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: +><i> +</I>><i> Well, I'm as far as possible from a threads expert, but I think that +</I>><i> what makes LinuxThreads special is that they are system threads (vs user +</I>><i> threads) maybe heavier, but making use of SMP, so basically, I think +</I>><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> |