Re: Using NSThreads in command-line apps

FROM : ben syverson
DATE : Fri May 16 06:50:35 2008

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