[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

74: Re: command parsing

[Full Header] [Plain Text]
From: claw@null.net
Newsgroups: nu.kanga.list.mud-dev
Date: Mon, 17 Mar 97 09:38:35 -0800
References: [1]
Organization: Kanga.Nu
Uhh, guys, can we get back to attributing quotes please.  If your mailer
doesn't  do it automagically, just prepending a [AlexO], [ChrisG], or
whatever at the appropriate quoting level at the start of the message
would be great.  

--
J C Lawrence                              Internet: coder@null.net
----------(*)                              Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
ted in how your pool of threads manages socket > connections. Are these threads dynamically created to manage connections? > That is, do you n+1 threads managing your connections, where n is active > connections plus one to handle connection requests on the master socket? > Are sockets blocked or do you use some other method of activating threads? This is really really crude, as its very long time since I looked at this code: One thread watches the master socket and spawns connection sockets from there as they come in. The child sockets then go into a pool (actually I think its a bag?) with a monitoring thread. Any IO to or from a socket is then assigned on a first available basis to a thread from a waiting pool of IO threads. Should an IO request come in which does not have a waiting thread ready to execute it, a new thread is created to process the IO. Should the number of IO threads significantly exceed the number of open sockets, then IO threads are killed down to a base minimum. As such the total number of IO threads is proportional to the current maximum rate of IO transactions thru the system. I could be way off here, but I think the above is fairly accurate, well sorta, maybe. >> Well, given an SMP machine, with an OS that will intelligently distributes >> threads -- that all semi happens for free with me (its not quite so good >> as I try to minimise thread creations, as few to no current OS'es will >> migrate a thread across processors for load sharing). On the other side, >> a definite design goal of my server is for it so support running in >> clustered enviroments where the entire cluster presents a single >> representation of a game. >It is my understanding that many OSs that implement multi-processing will >allocate one CPU for the OS and the rest of the available units to >application threads. NT 3.51 does this as well as many Unixes. I thought OS2 > used this model also. (please correct me if I'm wrong) AFAIK not even NT is quite this dumb (much tho I'd like to believe it). The process NT and OS/2 both follow, as well as most other MT SMP OS'es is to allocate new threads to the least busy CPU. I suspect that the source of your confusion is that NT and OS/2 both (largely) have a monolithic kernal (ie, a single thread). As such, yes, that primary thread will get allocated to one CPU at IPL. However, even OS/2 doesn't have a purely monolithic kernal any more, and so it will straddle multiple CPUs at IPL quite nicely. >It is also my understanding that NT 4.0 uses a different model and >implements "load sharing" as you define it above. I have heard rumors that >Digital's 64-bit Unix uses the "load sharing" model. Does anyone have any info >on this? None here. -- J C Lawrence Internet: coder@null.net ----------(*) Internet: coder@ibm.net ...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...