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/000280.html | 96 +++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 pipermail/nel/2001-February/000280.html (limited to 'pipermail/nel/2001-February/000280.html') diff --git a/pipermail/nel/2001-February/000280.html b/pipermail/nel/2001-February/000280.html new file mode 100644 index 00000000..d99dd3a6 --- /dev/null +++ b/pipermail/nel/2001-February/000280.html @@ -0,0 +1,96 @@ + + + + [Nel] NeL Network Engine + + + + + + +

[Nel] NeL Network Engine

+ Ian Holsman + nevrax@holsman.net
+ Mon, 26 Feb 2001 12:54:15 -0800 +

+
+ +
On 26 Feb 2001, you wrote in games.nevrax:
+
+ >Bernard Hugueney wrote:
+ >
+ >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 ...
+
+for discussions on different threading models you really should be 
+looking at, and drill down to the documents/technical papers.
+you probably don't want to maintain a thread per connected user, but
+have some kind of 'state' information which can be refered to by the 
+incoming request.
+
+
+http://www.cs.wustl.edu/~schmidt/ACE.html
+
+..Ian
+
+
+
+ + + + + + + + + + + + + + + + + + + + + + + +
+

+ -- cgit v1.2.1