I realize NSOperation on it's own does not spawn treads. I was
referring to the broader use of it. Surely, you knew that!
On Apr 11, 2008, at 8:08 AM, Bill Garrison wrote:
On Apr 11, 2008, at 7:35 AM, Don Arnel wrote:
Actually, while reading up on NSThread I cam across NSOperation
which
On Apr 11, 2008, at 7:35 AM, Don Arnel wrote:
Actually, while reading up on NSThread I cam across NSOperation
which appears to spawn a new thread but is supposedly much cleaner
to work with. It definately does the job for me. Thanks everyone for
your help with this problem.
NSOperation d
Actually, while reading up on NSThread I cam across NSOperation which
appears to spawn a new thread but is supposedly much cleaner to work
with. It definately does the job for me. Thanks everyone for your help
with this problem.
- Don
On Apr 10, 2008, at 5:13 PM, Wade Tregaskis wrote:
Th
On Apr 10, 2008, at 4:13 PM, Wade Tregaskis wrote:
Threads are almost always the right way to do what the OP wants.
Agreed. Furthermore, if you have the luxury of targeting Leopard,
look into NSOperation and NSOperationQueue. Using those properly,
you can get maximum concurrency for the h
Depending on the nature of your simulation, and if you don't mind
being Leopard-only, you might break it down into a series of
NSOperations and let Cocoa handle the rest for you.
Mike
On Apr 10, 2008, at 11:00 AM, Don Arnel wrote:
Hey all...
This is my first time posting to this list. I'
Threads are almost always the right way to do what the OP wants. The
problem as was presented is that there's some work to do, which
happens to be dividable into N segments. There were no bounds placed
on how long it takes to run any individual segment. And even if there
were, they'd pro
On Apr 10, 2008, at 2:00 PM, Don Arnel wrote:
I've got a Cocoa application which runs a simulation loop 1000s of
times. Of course, this prevents any user interaction with the rest
of the program while the simulation is running. When I was
programming for Windows there was a call in Visual B
There's NSRunLoop's runUntilDate: or CFRunLoopRunInMode if you'd like
to avoid multithreading. Though threading on Mac OS X is pretty
lightweight and has plenty of ways to do inter-thread communication.
On Apr 10, 2008, at 12:00 PM, Don Arnel wrote:
Hey all...
This is my first time posti
On Thu, Apr 10, 2008 at 11:14 AM, Don Arnel <[EMAIL PROTECTED]> wrote:
> I thought maybe there was a simple message I could send to NSApp, but it
> looks like putting the loop in a new thread is the way to go. Thanks!
Likely throwing this loop off to an NSThread is the cleanest and most
efficient
I thought maybe there was a simple message I could send to NSApp, but
it looks like putting the loop in a new thread is the way to go.
Thanks!
On Apr 10, 2008, at 2:06 PM, Jamie Phelps wrote:
Maybe look into NSThread and see if it meets your needs. You'd run
your loop in the thread and k
Maybe look into NSThread and see if it meets your needs. You'd run
your loop in the thread and keep processing events like normal in the
main thread.
(I'm still rather new to Cocoa myself, so I hope I'm not misleading
you. The other list readers will correct me if I'm wrong.)
HTH,
Jamie
On Apr 10, 2008, at 8:00 PM, Don Arnel wrote:
Hey all...
This is my first time posting to this list. I've been a Windows
developer for many many years and have just recently started to
play around with Macs. I feel like a beginner all over again!
Anyway
I've got a Cocoa application
Hey all...
This is my first time posting to this list. I've been a Windows
developer for many many years and have just recently started to play
around with Macs. I feel like a beginner all over again! Anyway
I've got a Cocoa application which runs a simulation loop 1000s of
times. Of
13 matches
Mail list logo
