• 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: call scrollRangeToVisible in multi-threads cause application dead lock
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: call scrollRangeToVisible in multi-threads cause application dead lock


  • Subject: Re: call scrollRangeToVisible in multi-threads cause application dead lock
  • From: David Gish <email@hidden>
  • Date: Wed, 7 Mar 2007 10:28:15 -0600

Apple states that the AppKit is generally NOT thread safe. Why on earth would you think that having critical section in YOUR code would magically make the AppKit thread safe. Until or unless Apple makes the AppKit thread safe, you are out of luck and there is no way you can correctly call AppKit methods directly from multiple- threads.

It is certainly possible to call non-thread safe code in a threaded environment with critical sections in your code. Non-thread-safeness is what makes code "critical" to begin with. For example, the C++ STL (Standard Template Library) isn't thread-safe, but as long as you know that, you prevent simultaneous access to STL objects in YOUR code. Suppose you have an STL queue<> container and need to access it from multiple threads, a very common method of IPC. Whenever you need to access that object, you wrap the code in a critical section or lock a named mutex.


The reason many libraries aren't thread-safe is that it's not worth the overhead to make them so. The judicious use of critical sections and other threading interlocks is much more efficient. Multi- threading is essential to just about any multi-media application (games, video playback, web browsers, etc.) If we had to wait to wait for the whole world to be thread-safe, we'd have to do without.

All that said, it may not be possible to protect AppKit calls with standard thread interlocking. For example, a device context may come into play, which should only be drawn to from the main thread (ultimately an OpenGL limitation.)

Just my $.02,

David Gish




_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: call scrollRangeToVisible in multi-threads cause application dead lock
      • From: "Shawn Erickson" <email@hidden>
References: 
 >Re: call scrollRangeToVisible in multi-threads cause application dead lock (From: Erik Buck <email@hidden>)

  • Prev by Date: Re: Intercept keydown in edited cell
  • Next by Date: Re: call scrollRangeToVisible in multi-threads cause application dead lock
  • Previous by thread: Re: call scrollRangeToVisible in multi-threads cause application dead lock
  • Next by thread: Re: call scrollRangeToVisible in multi-threads cause application dead lock
  • Index(es):
    • Date
    • Thread