• 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
Cocoa really needs to be thread-safe
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cocoa really needs to be thread-safe


  • Subject: Cocoa really needs to be thread-safe
  • From: Steve Klingsporn <email@hidden>
  • Date: Fri, 1 Nov 2002 15:11:09 -0600

Cocoa really really needs to be thread-safe.
Using NSEvents and posting them to the main thread is a hack.
A hack that breaks down quickly when the main event loop is busy.
Thread safety is so 1993. What's going on, Apple? Be got this right.
The new performInMainThread stuff is not in Cocoa-Java.
Sometimes I have seemingly-random crashes.
When I try to reproduce them with System.out.println()'s sprinkled in my code, often they do not happen.
(Must be some timing issue)

If Cocoa is Apple's "next-generation framework solution," then I expect to see Apple correct these issues.

The world is asynchronous and threaded.

Performance of a multithreaded app using NSEvents to get the job done when the main thread is busy is like holding down a menu on Mac OS 9 when trying to do something else. Abysmal.

Cocoa is neat, but this problem really should be fixed. If you can't make it thread-safe from within, provide locking mechanisms and document where we should lock so things don't blow up.

Objective-C stack traces in crash logs are only so useful for Java-based applications.

A very simple way to make this hack break down completely is to hold down a button while events from other threads are being posted to the main thread. NSSounds stop playing (they're played by the main thread, apparently), events start welling up and aren't answered (main thread is busy serving the button click, apparently), but strangely, drawRect() gets called in your custom views.

Even though I call display() from some of my background threads, I notice when I poop out some results (Thread.currentThread()), that only the main thread seems to call drawRect() in my view. Only in one case did another thread call drawRect().

Does this mean I can put things that need to be run by the main thread in my view's drawRect(), and that if I call display() on my view, they will get run by the main thread and not block when a button is down?

Thanks,
Steve
_______________________________________________
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: Cocoa really needs to be thread-safe
      • From: James DiPalma <email@hidden>
    • Re: Cocoa really needs to be thread-safe
      • From: Andy <email@hidden>
    • Re: Cocoa really needs to be thread-safe
      • From: Dave Rehring <email@hidden>
  • Prev by Date: NSBitmapImageRep - draws in 32bit, but not in 16bit depth
  • Next by Date: Re: Cocoa really needs to be thread-safe
  • Previous by thread: Re: NSBitmapImageRep - draws in 32bit, but not in 16bit depth [SOLVED]
  • Next by thread: Re: Cocoa really needs to be thread-safe
  • Index(es):
    • Date
    • Thread