"Portable" way to do message passing between threads?

Question

(I posted this on the Apple Developer Forums already, but since that forum is only accessible to registered and paid iPhone developers, I thought it would be nice to put it here as well so as to get some more potential eyeballs on it. I apologize if this kind of "cross-posting" is not kosher/is frowned upon around here.)
Hey everybody,
"Long-time listener, first-time caller," heh.
I've been working for the past 2-3 months on my very first iPhone app. Actually, what I've been working on is a framework that I plan to use in an iPhone app of my own but which I am also trying to write for the "lowest-common-denominator" so that I (and others) can use it in other apps written for both Mac and iPhone.
Not only is this my first time writing an iPhone app, it is my first time writing for any Apple platform. In fact, it is my first time using Objective-C, period. I cannot stress this enough: I am a "n00b." So go easy on me. I also have not worked with threading before this, either, on any platform, so the learning curve for me here is rather significant, I'm afraid. I am NOT afraid of either taking the time to learn something properly OR of rolling up my shirtsleeves and working. However, on account of my experiences so far, I am finding myself (not to flame or anything!) quickly becoming frustrated by and disillusioned with not so much Objective-C itself, but the Foundation frameworks.
So with that said, read on, if you dare...
The basic idea behind my project is that the framework I am writing will present an API to developers which will allow them to write client apps that interact with a particular network appliance or network-aware embedded system. I already have my basic set of classes up and functioning, and the framework works to my satisfaction both on MacOS and iPhoneOS. The platforms I am targeting are MacOS X Tiger 10.4 and later, and iPhoneOS, and up until this point, I've managed to keep a codebase that works on all of the above.
What I wanted to do next was add some multithreaded goodness to the mix. (Woe is me.) I have asynchronous network socket I/O working within the main thread, and it, in fact, works a treat. In my test app on the phone, I've managed to keep the UI nice and responsive by using the main thread's runloop efficiently. But even though TCP async I/O works fine within the main thread, I want to be able to split out and offload the processing of any data received by the app from the appliance to its own thread. (It is possible, and even desirable, for an application using this framework to be connected to multiple appliances simultaneously.)
My idea, in order to try to keep things as simple and as clean as possible, was to implement a wrapper class that presented my other main class as an "actor." So, rather than instantiating my main class, one would create an instance of the wrapper class which would in turn control a single instance of my main class and spawn its own thread that the network connection and all data processing for that particular connection would run within.
(I hope I'm making sense so far...)
Out of the gate, writing a subclass of NSThread sounds like the logical design choice for an "actor-type" thread, but because I was trying to maintain Tiger compatibility, I stuck with +detachNewThreadSelector:etc.
Once I decided to pursue the actor model, though, the main problem presented itself: how to best pass messages between the main thread and all of the "actor" threads that might be spawned?
I stumbled upon -performSelector:onThread:withObject:, and knew instantly that this was exactly what I was looking for. Unfortunately, it doesn't exist on Tiger; only its much more limited little brother -performSelectorOnMainThread:withObject: does. So I kept looking.
All of the pre-Leopard documentation, tutorials, and sample code that I read indicated that to pass messages between threads, I needed to basically pretend that the threads were separate processes and use the expensive Distributed Objects mechanism to get messages back and forth. Unfortunately, even if that WAS a desirable option, iPhoneOS does not have any support for DO! Grrr...
Finally, I thought I found the answer when I ran into a third-party solution: the InterThreadMessaging library from Toby Paterson (available @ http://homepage.mac.com/djv/FileSharing3.html). In this library, the author basically implemented his own version of -performSelector:onThread:withObject: called -performSelector:withObject:inThread:. Sounds close enough, right? And actually, it is pretty darn close. It's made to do exactly what it sounds like, and it does it in a platform-neutral way that works on pre-Leopard systems as well as iPhoneOS, using Mach ports instead of DO.
(...wellll, ALMOST. I discovered after I built a small test app around it that it actually isn't "iPhone-clean." The author used an NSMapTable struct and the NSMap*() functions, which don't exist in iPhoneOS, and he also implemented the handlePortMessage delegate method, but although iPhoneOS has NSPort, it DOESN'T have NSPortMessage. GAAARGH. So I took the time to replace the NSMapTable stuff with NSValue-wrapped objects inside of an NSMutableDictionary, and replaced the handlePortMessage method implementation with a handleMachMessage method, which took some doing because I had to figure out the structure of a Mach message, NO thanks to ANY of the available documentation...)
Once I started using it, though, I quickly discovered that this implementation wasn't up to snuff. My "actor" class and my main thread will be passing a ton of messages to each other constantly whenever there is network activity, and with InterThreadMessaging, I found that whenever activity started to ramp up, it would collapse on itself. This mostly took the form of deadlocks. I found a note that someone else wrote after experiencing something similar with this library (quoted from DustinVoss @ http://www.cocoadev.com/index.pl?InterThreadMessaging):
"It is possible to deadlock this library if thread A posts a notification on thread B, and the notification on B causes a selector or notification to be posted on thread A. Possibly under other circumstances. I have resolved this in my own code by creating an inter-thread communication lock. When a thread wants to communicate, it tries the lock to see if another thread is already using the InterThreadMessaging library, and if it can't get the lock, it posts a message to its own run-loop to try again later. This is not a good solution, but it seems to work well enough."
So I tried implementing what he described using a global NSLock, and it did help with some of the deadlocks. But not all. I believe the culprit here is the Mach ports system itself (from the NSPortMessage documentation for -sendBeforeDate:):
"If the message cannot be sent immediately, the sending thread blocks until either the message is sent or aDate is reached. Sent messages are queued to minimize blocking, but failure can occur if multiple messages are sent to a port faster than the portís owner can receive them, causing the queue to fill up."
InterThreadMessaging in fact calls -sendBeforeDate: and exposes the deadline option, so I tried setting a really short time-to-live on the Mach messages and then intercepted any NSPortTimeoutExceptions that were thrown; upon catching said exceptions, I would then re-queue up the message to be sent again. It worked, but Performance. Was. A. Dog. At least the message queue wouldn't be full indefinitely anymore, causing the main thread to block, but during the whole time that these messages were expiring because the queue was full and then being re-queued, either the main thread was trying to send more messages or the actor thread was trying to send more messages. And as far as I can tell, the Mach ports queue is global (at the very least, there is seemingly only one per process). The message would get through with this model...eventually.
JUST IN CASE the problem happened to be something I screwed up as I was rewriting portions of the InterThreadMessaging library so that it would compile and work on the iPhone SDK, I substituted in the original version of the library in my Mac test app to see if any of these problems became non-issues. I found that both versions of the library -- mine and the original -- performed identically. So that wasn't it.
Finally, in frustration I said, "screw it, I'm going to try it the Leopard way," and replaced all of the method calls I was making to InterThreadMessaging's -performSelector:withObject:inThread: with calls to Foundation's native -performSelector:onThread:withObject: instead, changing nothing else within my code in the process. And wouldn't you know: IT WORKED GREAT. Performance was (and is) fantastic, about on-par with the non-threaded version when only dealing with a single connection/instance of my class.
So, in the end, I was able to do nothing to salvage the InterThreadMessaging implementation of cross-thread method calling, and as far as I can tell, I'm out of (good) options. And thus my mind is filled with questions:
How is the Leopard -performSelector:onThread: method implemented? I'm guessing not using Mach ports, given that I didn't have the same blocking & deadlocking problems I had with InterThreadMessaging. Is it possible to re-implement this Leopard+ method in a similar manner as a category to NSObject under Tiger? Or is it possible, perhaps, to increase the size of the Mach ports queue so that InterThreadMessaging works at a sane level of performance? Or -- I'm getting desperate here -- is there any way that I could trick -performSelectorOnMainThread: to target a different thread instead? (I am assuming here that -performSelectorOnMainThread is implemented under-the-hood much like the new -performSelector:onThread: is implemented, but with a hard-coded NSThread pointer built-in to the code, and that the new method just exposes a more flexible interface to what is basically the same code. I'm probably wrong...) Is there another third-party library out there that I've missed that fits my requirements for being able to do message-passing between threads in an efficient and portable manner?
I refuse to believe that there is no way for me to maintain compatibility with all of the platforms I wish to support without having to resort to making preprocessor #ifdef spaghetti out of my code. And there SURELY has to be a better way of doing cross-thread message passing in Tiger without using Distributed Objects, for Pete's sake! Is this really how people did it for years-on-end since the dawn of NeXT up until the advent of Leopard? And if there really, genuinely wasn't another alternative, then what is up with the lack of DO in iPhoneOS?? Does Apple seriously intend for developers who have good, solid, tested and working code to just chuck it all and start over? What if there was some aspect of DO that previous implementations relied upon that cannot be recreated with simple -performSelector:onThread: calls? (I don't know what those aspects would be...just a hypothetical.) I mean, I can understand needing to write new stuff from scratch for your UI given how radically different the interface is between the Mac and iPhone, but having to reimplement back-end guts such as something as elemental as threads...really?!
I do laud the inclusion of the new method in Leopard as well as the new ability to subclass NSThread itself. But for those of us that need to support Tiger for one reason or another, some of these restrictions and omissions within iPhoneOS seem like rather pointless (and frustrating) roadblocks.
As I hope is obvious here, I have tried to do my homework before throwing up my hands and pestering y'all. If you have the patience to deal with me, please tell me what I am missing.
Thanks for taking the time to read,
-- Nathan

Answer 1

Thanks again for your patience. Comments below.
etresoft wrote:
It is pretty unusual that anyone would want to call perfomrSelector on any thread other than the main thread.
What I described in my original post was not a worker thread, but an "actor."
It is hard for me to answer this question because there are so many options available to do "message passing". The fact that you think there are so few tells me that you really aren't sure what you need to use.
I didn't say there were few options for message passing. I said there were few options for message passing that fit my criteria, which are that any potential solutions should both A) work efficiently and with good performance, and B) be available both pre-Leopard AND on the iPhone. -performSelector: ain't available before Leopard. Distributed Objects is overkill. Kernel Mach messages apparently have a high overhead, too, as my experience with the third-party library I wrote about in my original message shows.
...consider notifications.
I thought notifications couldn't be posted across threads, either. How do I post a notification to another thread's default notification center or notification queue from a different thread?
The notification center is owned by the process. Each run loop can listen for just the notifications it wants. You don't "pass" or "send" notifications, you run then up the flagpole for all to see.
I am aware of how to use notifications. The documentation for NSNotificationCenter clearly states that "In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself."
So, again, I don't see how one thread can post a notification in such a way that the observer's registered method is executed in another thread (posting notifications "across threads"). This probably isn't a big deal if you are using mutexes (assuming you don't actually care which thread carries out the task associated with the notification posting), but as I said before, this is not what I'm after.
I don't know what you are really after.
Allow me to attempt to explain a second time, in a more concise fashion.
My app will have multiple, persistent TCP connections open, one connection per remote device. The user will be able to select a task to execute on a particular device that we have a connection open to, and get back from the application real-time updates as to the progress or results of the execution of that task. In certain cases, the length of the task is infinite; it will keep executing forever and sending back results to my application which will update its display of the results every second that ticks by until the user STOPS that particular task.
This can be done simply using async I/O in the main runloop, sure. But if I were going to thread this so that I could be processing the results I've received back from one *or more* remote devices while also doing something else, given that I will only have one (persistent) connection open to any given remote device that I'm interacting with (that is to say, I won't be opening up a separate TCP session for every single task I want to execute on a single device simultaneously), it makes sense _to me_ to implement this as I've described: with every connection to each remote device getting its own thread that lasts for the lifetime of the TCP session (which could be the entire time the application is running, times however many devices the user wishes to be connected to while in the app). I won't be spawning a new thread for every task the user wishes to ask a remote device to do.
This is why (I think) I need bi-directional messaging between the main thread and each of these threads dedicated to a given remote device that we have an active session with/connection to. The main thread needs to be able to tell remote device X (which already has a running thread dedicated to it) to do task A, and then get real-time feedback from that remote device so that the main thread can be displaying it to the user as it is coming back. Same with remote device Y running task B, simultaneously. At any time during the execution of these tasks, the user needs to be able to tell my app to stop one of these tasks, and the main thread needs to send that message to one of the remote devices via that device's dedicated thread.
This is why I am talking about this in terms of the "actor model," and not the "worker thread model," because the former model seems to fit what I want to do.
-- Nathan