On Wed, Jun 18, 2008 at 1:50 PM, Pierce T. Wetter III <[EMAIL PROTECTED]> wrote: > The problem is that creating a thread, destroying a thread, and switching > threads in and out have a LOT of overhead. The above thread is going to > spend most of its time waiting for I/O, but the OS has no way of knowing > that really. So the OS swaps in the thread, which looks at its mutex and > says "I have nothing to do", and then gets swapped out.
I'm sorry but I have to take issue with this. Are you saying that the scheduler is not intelligent enough to keep the apps on a blocked queue until a packet comes in for that handle, at which point the process is awoken and sent a signal? > Trivia: Apache 1.x is even worse then this, it forks off a whole new > _process() per connection so you have even more overhead. That's one of the > reasons people tend to put caches in front of apache for performance > (webperfcache on OSX Server, squid on others). I'd say the fact that this model is still the default points towards its persistence as an engineering tradeoff. But overall I agree with you 100%. Threads are most useful when you have a major task (calculate pi) and a minor task (print digits as they're computed), and do not want or cannot have the minor task suffer for the major task. You still want to consume your entire timeslice with performing the single, heavy task. Web serving, on the other hand, is a bajillion tiny tasks, and better methods exist to accomplish that goal. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
