Re: Using NSThreads in command-line apps
Re: Using NSThreads in command-line apps
- Subject: Re: Using NSThreads in command-line apps
- From: ben syverson <email@hidden>
- Date: Thu, 15 May 2008 23:50:35 -0500
On May 15, 2008, at 8:02 PM, Jens Alfke wrote:
I don't think the difference will be noticeable, if indeed there is
any, unless you're trying to write The World's Fastest Web Server.
Usually the important factor is how many hours it takes you to write
and debug the code, not how many microseconds the program takes to
handle a request.
Perhaps the difference will be small... I'll be sure to post here when
I test it. A few microseconds here and there can really add up,
though. :) Apache begins to choke once you get to even 100 connections/
sec, which is why I'm not just doing this in mod_perl. CGI and FastCGI
are out of the question (too much overhead), so I'm stuck rolling my
own. Using kqueue is a way to be certain that request handling will
not be the bottleneck in my code.
The thing is, by running your own blocking loops, you're going
against the grain of the way the Cocoa frameworks do things. It
doesn't mean you can't do it that way, but you won't be able to use
NSRunLoop or anything built on it on threads where you're doing that.
I'm not sure I'm missing anything NSRunLoop has to offer. After
reevaluating my code, I don't think I need to run methods on my server
thread from the worker threads, so I don't need the
performSelectorOnMainThread: method after all. I just use an
NSConditionLock to run the worker threads when the request queue has
items, and another lock to write them to an output queue...
- ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden