• 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: setNeedsDisplay broken in Tiger
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: setNeedsDisplay broken in Tiger


  • Subject: Re: setNeedsDisplay broken in Tiger
  • From: Bob Ippolito <email@hidden>
  • Date: Wed, 25 May 2005 00:07:44 -0700


On May 24, 2005, at 9:43 PM, Andrew Thompson wrote:


On May 24, 2005, at 4:01 PM, Troy Stephens wrote:


On May 24, 2005, at 11:32 AM, Troy Stephens wrote:As Bob Ippolito pointed out, messaging views from a secondary thread is in general not thread-safe and therefore not a recommended practice, on any version of Mac OS X.
To clarify a bit: There _are_ some aspects of view functionality that are OK to use in a multithreaded manner. For example, locking focus to draw in a view on a secondary thread is supported.


The -setNeedsDisplay: and -setNeedsDisplayInRect: operations, however, are not thread-safe, and should therefore always be performed on the application's main thread.


Interesting contrast with Java AWT, where the repaint() method on Component is one of the very few AWT/Swing operations which *is* explicitly thread safe and can be called from any thread.


Of course, they achieve that by queuing repaint events on the AWT event queue and thus actually firing the paint from the AWT Thread "some time later" (thus it really is serial, but the application developer can ignore that). This does allow them to do repaint coalescing to cut down on unnecessary paints.

How interesting that -setNeedsDisplay: is exactly the opposite; it would seem a perfect candidate for some kind of queue... I'd love to know why it's that way :)

It's not that way, you're mistaken. Calling setNeedsDisplay: doesn't cause anything to happen immediately either, but it's not safe to call from random threads whenever you want to. Read the docs, when a view is set as needing display, it will be displayed during the next pass of the event loop.


Cocoa's threading model is quite simple: unless something is explicitly thread safe, it's almost certainly not. If it happens to be, pretend it's not, because that's an implementation detail that's subject to change. Threads should be rather isolated from one another in general; so if you find yourself wishing that more of Cocoa was thread safe, then you should probably learn some more about preemptive multithreading first.

-bob

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: setNeedsDisplay broken in Tiger
      • From: Andrew Thompson <email@hidden>
References: 
 >setNeedsDisplay broken in Tiger (From: John Nairn <email@hidden>)
 >Re: setNeedsDisplay broken in Tiger (From: Troy Stephens <email@hidden>)
 >Re: setNeedsDisplay broken in Tiger (From: Troy Stephens <email@hidden>)
 >Re: setNeedsDisplay broken in Tiger (From: Andrew Thompson <email@hidden>)

  • Prev by Date: NSView redisplay - what am I missing?
  • Next by Date: Re: NSView redisplay - what am I missing?
  • Previous by thread: Re: setNeedsDisplay broken in Tiger
  • Next by thread: Re: setNeedsDisplay broken in Tiger
  • Index(es):
    • Date
    • Thread