• 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: Thread Communication Conceptual Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread Communication Conceptual Question


  • Subject: Re: Thread Communication Conceptual Question
  • From: Alastair Houghton <email@hidden>
  • Date: Thu, 2 Aug 2007 11:20:54 +0100

On 2 Aug 2007, at 10:54, Chris Suter wrote:

On 02/08/2007, at 7:45 PM, Andrew Farmer wrote:

On 02 Aug 07, at 02:42, Filipe Varela wrote:
AFAIK, and based on something i wrote (check out www.dev6.com under the blog section, release 1 of the flightcontroller code), if you do signal handling, the signal handler is always executed on the main thread. Could that be used to pass messages to the main thread in your case?

Apart from being an awful way to do things, I believe it's also wrong:

http://developer.apple.com/qa/qa2001/qa1184.html

and even if it wasn't wrong, there'd be no guarantee the behaviour would stay that way.

It's *definitely* wrong. SUSv3/POSIX says so.

<http://www.opengroup.org/onlinepubs/000095399/functions/ xsh_chap02_04.html>

Executive summary:

There are two types of signals---those that are associated with a particular thread (e.g. those caused by illegal instructions, floating point exceptions, access violations and the like), and those that are not.

The former are delivered to the thread that caused them. The latter may be delivered to any thread in the process that is not currently blocking their delivery.

On 2 Aug 2007, at 10:42, Filipe Varela wrote:

Could that be used to pass messages to the main thread in your case?

Signals are *evil*, and you shouldn't be using them for inter-thread communication.


There are plenty of ways to pass messages to the main thread that do not rely on signals. If you're after something that will work with Carbon and Cocoa apps, well, both of them use a CoreFoundation run loop, so you can use anything that will work with that. You could create a CFRunLoopSource and use that to signal the main thread, for instance.

If you want total portability, then it gets a little complicated because it really depends on how the main thread of the process you're running in is written. A lot of UNIX apps have a select() or poll() loop in their main thread, so (for instance) an anonymous pipe might be an appropriate solution in that case.

Kind regards,

Alastair.

--
http://alastairs-place.net


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please 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


References: 
 >Thread Communication Conceptual Question (From: Eyal Redler <email@hidden>)
 >Re: Thread Communication Conceptual Question (From: Filipe Varela <email@hidden>)
 >Re: Thread Communication Conceptual Question (From: Andrew Farmer <email@hidden>)
 >Re: Thread Communication Conceptual Question (From: Chris Suter <email@hidden>)

  • Prev by Date: Re: Using -interpretKeyEvents in NSTextView to interpret key events
  • Next by Date: Re: Thread Communication Conceptual Question
  • Previous by thread: Re: Thread Communication Conceptual Question
  • Next by thread: Re: Thread Communication Conceptual Question
  • Index(es):
    • Date
    • Thread