Hi all,
I have a bit of a dilemma. I'm working on a Foundation-based command-
line utility that needs to manage a few threads. The obvious choice is
NSThread, since it's nice and clean.
Actually, I'm able to spawn new threads perfectly well. The problem is
that I can't (?) use performSelec
On May 15, 2008, at 1:47 PM, Bill Bumgarner wrote:
Run an NSRunLoop on your main thread. That'll support -
performSelectorOnMainThread:.
Okay -- interesting. One follow-up question... my core loop is
basically:
while(_running) {
// do stuff
}
I don't want to listen to any input,
On May 15, 2008, at 1:49 PM, Randall Meadows wrote:
Can't you cache the main thread [NSThread +currentThread] when you
start up, and then use NSObject's -
performSelector:onThread:withObject:waitUntilDone: method?
Yes, that would be ideal! Unfortunately that method is 10.5 only...
- ben
__
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
On May 15, 2008, at 4:17 PM, Jens Alfke wrote:
You can wire up kqueues to a runloop fairly easily. Instead of
blocking, the kqueue will post an event to the runloop when
something happens. Then instead of waiting in kevent, you just
handle events in your runloop, and your callback will be i
On May 15, 2008, at 5:33 PM, Hamish Allan wrote:
NSRunLoop is just Cocoa's implementation of a kevent()-style loop.
Instead of adding your socket to the kqueue, add it to the run loop
instead. (See e.g. http://cocoadevcentral.com/articles/39.php --
which uses the CFRunLoop interface, but it
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 micros
On May 18, 2008, at 8:39 PM, Julius Guzy wrote:
Well this is exactly how things seem to pan out. Those who have been
doing this for some time like the documentation they have. No doubt
once I become a bit more adept I will too. But right now..
This is going to sound bitchy, but it's ha
On May 19, 2008, at 12:03 AM, Peter Duniho wrote:
From: ben syverson <[EMAIL PROTECTED]>
This is going to sound bitchy, but it's hard for me to have any
sympathy for vague complaints about the docs or the usability of
Cocoa.
That does sound bitchy. I mean, it's fair en
On May 19, 2008, at 1:54 PM, Michael Vannorsdel wrote:
I'm just saying Cocoa delegates don't always act in dictionary form.
I know this discussion can go round and round, but I still think
reading the english dictionary for delegates won't tell you the
whole story on Cocoa delegates.
Wit
On May 19, 2008, at 3:36 PM, Peter Duniho wrote:
I appreciate the example. It's certainly reasonably elegant and to
the point, and it's more "real world" than some of the other ones
(bridging Cocoa to another language? yeah, right...a) it's not like
you can't interface between languages
11 matches
Mail list logo
