• 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
Help with understanding distributed objects and UI?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Help with understanding distributed objects and UI?


  • Subject: Help with understanding distributed objects and UI?
  • From: Dave Camp <email@hidden>
  • Date: Mon, 7 Oct 2002 13:15:15 -0700

I'm trying to use DO for the first time and I was wondering if people more knowledgeable than I could set me straight.

My app starts a thread that checks a remote server to see if any software updates are available. If there is a new version available, I want to ask the user if they want to download it. The desired secondary thread behavior is: check for updates->ask user->download file->fall off end of thread.

The Cocoa threading docs are a bit wishy-washy about how much, if any, UI operations can be done on secondary threads. Being unsure, I decided to have my secondary thread send a DO message to the main thread to issue the alert dialog (app modal) and pass the result back.

This seems to result in crashes and other unintended weirdness. What I expected to happen would be that the message from the secondary thread would be executed on the main thread at a safe time (like sending custom Carbon events in a Carbon app, which are picked up in the event loop, avoiding reentrancy issues). Instead, the messages appear to be executed somewhat immediately in the main thread, almost interrupting whatever the main thread is doing.

For example, I can set a breakpoint in my "displayDialog" message handler in the main thread, and when it is called, I'm stopped in the main thread (not the secondary thread that sent the message), but the stack shows the main thread was in the middle of doing other UI stuff (updating an unrelated table view), some CFRunLoop stuff happens, and then the incoming message is processed smack in the middle of that.

The DO docs led me to believe it was supposed to solve problems like this, but I'm not seeing it in my code. Am I doing something wrong, or does DO only tackle the issues of thread synchronization and object sharing, not avoiding reentrancy issues?

Can someone point me to any documentation with more clear explanations of when and how the messages are executed? Also, when are "oneway" messages executed on the receiving thread?

Are there any Cocoa objects or constructs that allow secondary threads to send messages to the main thread that avoid reentrancy by deferring them to event processing time (like a Carbon event)?

Or, am I trying to solve this problem in the "wrong" way?

Thanks,
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.
  • Prev by Date: Re: Newbie ImageWell question
  • Next by Date: Re: NSDragOperationDelete
  • Previous by thread: drag and drop
  • Next by thread: NSMutableArray performance
  • Index(es):
    • Date
    • Thread