• 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: Andrew Thompson <email@hidden>
  • Date: Wed, 25 May 2005 10:00:30 -0400


On May 25, 2005, at 3:07 AM, Bob Ippolito wrote:

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.

That makes perfect sense, it just leaves me wondering why what's presumably such a simple method wouldn't be thread safe. One wonders if it's an efficiency thing - assuming it's just a boolean flag, then you'll have problems unless NSLock (or possibly volatile) is used to make the changes visible across threads. Or maybe it's something else entirely. That's what I'm curious about, but I doubt anyone at Apple is going to say :)


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.

The exact same rule applies to AWT/Swing in Java for precisely the same reasons. Very few methods are documented thread safe.
Many things in fact do work from multiple threads, but, especially if you're targeting multiple platforms, you're better off behaving as if they're not thread safe and doing everything from the AWT thread, which plays the role of the main thread in AppKit.


So you're preaching to the choir here. I understand the principle, and whilst it would be nice if more things in both toolkits (Cocoa, AWT/Swing) were thread safe, it's certainly no silver bullet! I'm just curious about the reasons behind things.

AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside

        (see you later space cowboy ...)

_______________________________________________
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: John Stiles <email@hidden>
    • Re: setNeedsDisplay broken in Tiger
      • From: Ondra Cada <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>)
 >Re: setNeedsDisplay broken in Tiger (From: Bob Ippolito <email@hidden>)

  • Prev by Date: Re: Working set bloat in Xcode 2
  • Next by Date: Re: NSHost and NSOutputStream question
  • Previous by thread: Re: setNeedsDisplay broken in Tiger
  • Next by thread: Re: setNeedsDisplay broken in Tiger
  • Index(es):
    • Date
    • Thread