On May 15, 2008, at 2:25 PM, Bill Bumgarner wrote:
Your main thread loop?
If that is the design you want to use, then you can use NSLock --
NSConditionLock, typically -- to do the synchronization between
threads. If your loop really is running flat out, then using a
condition lock will be marginally faster.
b.bum
Maybe... I should be more specific, so it's clear what I'm trying to
do. The application is a lightweight HTTP server which reads requests
on a socket and uses two or three worker threads to generate the
responses. I'm using kqueue / kevent instead of the Cocoa stuff.
I have one thread which runs the server's infinite loop. It can't be
the main thread, because it calls kevent, which doesn't return a value
until there's an event. So that thread's loop stops while kevent is
waiting.
When the server thread gets a complete request, it needs to be picked
up by a worker thread. Perhaps the way to do this is with an
NSConditionalLock? As in, the server thread would lock an
NSMutableArray, add the new requests, and that would trigger the
worker thread? If I go with that, I guess I wouldn't have to a
performSelectorOnMainThread:...
I want to go with whatever will give me the best performance. (I know,
I know, ObjC adds some overhead, but the advantages in readability
outweigh the messaging overhead for me. If I need to recode some parts
as ANSI later, I will.)
Thanks for all the responses so far!
- 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]
