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 (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]
