Can extra processing threads help in this case?
in [MFC]
|
From: Peter Olcott on 12 Apr 2010 21:10 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:3ou6s5lbtj3vb18uosoduk1gevbc6gljcn(a)4ax.com... > See below... > On Fri, 9 Apr 2010 20:36:34 -0500, "Peter Olcott" > <NoSpam(a)OCR4Screen.com> wrote: >>Yeah it sure does when you critique your misconception of >>my >>design instead of the design itself. I use the term >>PROCESSES and you read the term THREADS. Please read what >>I >>actually say, not what you expect that I will say or have >>said. > **** > The reason I don't distinguish between threads and > processes is that they are the same, > for purposes of the scheduler. Apparently not in Linux. > You later showed that you had confused REAL threads with > the unix pthreads (pseudo-threads) library, which explains > YOUR confusion! > joe > **** >> > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Peter Olcott on 12 Apr 2010 21:13 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:dbv6s519osh3qdv2l063sv98n5kbbd6t2m(a)4ax.com... > See below... > On Sat, 10 Apr 2010 08:47:00 -0600, Jerry Coffin > <jerryvcoffin(a)yahoo.com> wrote: > > Note that THREE people with real experience in building > complex systems have now told you > your design is wrong. You are 1 of 4 votes claiming it is > good. Has it occurred to you > that if several independent experts agree the design is > bad, that just maybe, it is bad? > joe Without sounding reasoning to back it up it might as well be three liars. I don't know who you are, you could possibly be an imposter. When it comes to discerning truth only sound reasoning forms a sufficient criterion measure. > **** > Joseph M. Newcomer [MVP] > email: newcomer(a)flounder.com > Web: http://www.flounder.com > MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Hector Santos on 12 Apr 2010 21:23 On Apr 12, 2:29 pm, "Pete Delgado" <Peter.Delg...(a)NoSpam.com> wrote: > > PS: Can we all get back to real MFC programs and real MFC programmers now??? > ;-) I just figured out how to filter him under my MUA (Thunderbird)! Yeepie! Gawd, I feel saved! Someone save Joe! <g>
From: Jerry Coffin on 12 Apr 2010 21:23 In article <6fe7s55u4fnmhjnq2qj3ctroi81iomsnk2(a)4ax.com>, newcomer(a)flounder.com says... [ ... ] > each packet has a forged IP address which is fictional, PRECISELY > so you can't use the IP address to detect and block the attack!) *Partly* so you can't detect and block the attack. Partly because when he's sending packets at a rate intended to bring down your server, the last thing he wants is replies from all those packets -- that might well take *his* server down, and if you have a bigger server than he does, chances are that his server would go offline before yours did (exactly the opposite of intent). -- Later, Jerry.
From: Jerry Coffin on 12 Apr 2010 21:31
In article <k_adnZQ1so5DJ17WnZ2dnUVZ_rednZ2d(a)giganews.com>, NoSpam(a)OCR4Screen.com says... [ ... ] > > But SQMS works better on single-core machines (see > > reference to that secret technique > > called "time slicing") > > So I am already doing that with my MQMS, and because I have > been told that Linux does not do a very good job with > threads, my implementation is likely superior to yours. I > have seen no reasoning to the contrary. What relationship do you see between multiple threads of execution, and multiple queues? You actually have things exactly backwards: with enough processor cores, separate queues start to gain an advantage due to lower contention over a shared resource -- though contention has to be quite high for that to apply. Even then, you basically have to take pretty careful (and frankly, somewhat tricky) steps to get the multiple queues to act like a single priority queue before you get any good from it. For a single processor, there's no room for question that a single priority queue is the way to go though -- a single hyperthreaded core simply won't even come code to producing the level of contention necessary to make multiple queues superior (something on the order of quad hyperthreaded cores might start to get close). -- Later, Jerry. |