• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Background app, NSStatusItem, tight loop, event handling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Background app, NSStatusItem, tight loop, event handling


  • Subject: Re: Background app, NSStatusItem, tight loop, event handling
  • From: Dave Camp <email@hidden>
  • Date: Thu, 5 Feb 2004 11:41:16 -0800

I'll start by saying I'm no expert on the inner workings of RunLoops. :-)

It's not obvious where the code you posted is being run. I assume it's being run from within an event handler of some sort (i.e in response to your menu being clicked). Thus, you are trying to run the run loop while the run loop is processing the current event. From past experience I've discovered that the current run loop will not continue to process the event queue until processing on the current event is complete (i.e. you do something in your handler and return control). I suspect it is designed this way on purpose to prevent reentrancy issues which would make for some serious coding headaches.

The correct way to handle tasks that require a long time to complete, and thus block event processing on the main thread, is to run the task in it's own thread. As someone else mentioned earlier, this is easily done with:

NSThread and detachNewThreadSelector:toTarget:withObject:

Locking issues come into play when the main thread needs to get/set information that may be shared with the thread. Read the section in the Cocoa docs about NSThread and NSLock. If your needs are simple, you can probably just create an NSLock in the object to be run on the separate thread and have all your get/set methods lock/unlock when accessing member variables. If your needs are more complex, you might need more locks, conditional locks, etc.

Hope that helps,
Dave

On Feb 5, 2004, at 11:22 AM, Dave Hersey wrote:

Hi Dave,

I'm willing to multi-thread the code if need be, but I don't understand why
that would work if giving the run loop as much as 10 seconds to process
events isn't enough for it to process a mouse down in its status menu.

I'm sure I'm going to run into some locking issues if I use threads, and I
don't want to pursue that unless it's clear that using threads will fix the
problem.

So, why will spawning threads get my events processed, when giving excessive
time to the run loop won't?

Thanks,

- d

The correct solution would be to move your tight loops into a separate
thread, which would leave the main thread available for event
processing. I would suggest reading the documentation for NSThread and
friends.

Dave



---
Among the chief weapons of UNIX: Fear, surprise and ruthless efficiency.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
  • Follow-Ups:
    • Re: Background app, NSStatusItem, tight loop, event handling
      • From: Dave Hersey <email@hidden>
References: 
 >Re: Background app, NSStatusItem, tight loop, event handling (From: Dave Hersey <email@hidden>)

  • Prev by Date: Re: string drawing again
  • Next by Date: Re: NSArrayController, custom objects, user defaults
  • Previous by thread: Re: Background app, NSStatusItem, tight loop, event handling
  • Next by thread: Re: Background app, NSStatusItem, tight loop, event handling
  • Index(es):
    • Date
    • Thread