On 5/6/10 1:57 PM, "Jens Alfke" <j...@mooseyard.com> wrote:
> > > On May 6, 2010, at 10:34 AM, McLaughlin, Michael P. wrote: > >> Is there a recommended way of determining that the currentRunLoop in a >> subordinate task (executable) is, in fact, running and ready to >> receive a >> distributed notification? > > No. That's really not what distributed notifications are for. They're > not a general purpose IPC mechanism, they're to notify some > unspecified set of listeners that something has happened, usually a > change in some system or app state (i.e. the system text highlight > color, or the current song in iTunes.) The assumption is that a > process that wasn't running when the notification was sent will check > the current state when it starts up anyway. > >> Later, after a File Menu selection in the app, the app informs the >> subtasks >> of the selection via >> >> [[NSDistributedNotificationCenter defaultCenter] >> postNotificationName:@"newCase" object:[notif object]]; > > You should come up with some other IPC mechanism to use here. This > kind of tightly coupled messaging isn't right for distributed > notifications. (In particular, be aware that distnotes can be dropped > on the floor if the receiving process's Mach message queue overflows.) > > A typical way to do this is to use stdin/stdout for communication. To > send data to a subtask you write to its stdin pipe, and it sends you > data by writing to stdout. NSTask makes it fairly easy to set up these > pipes and monitor them asynchronously. > > (Also, not meaning to sound patronizing, but are you sure you need to > run separate processes instead of just multiple threads? Inter-thread > communication is a lot simpler, and you avoid the performance and > resource overhead of spawning processes.) I tried for a long time to get threads to work but they did not, even to the extent, sometimes, of seeing reverse scaling (longer runtimes with more threads). The reason, in my case, is almost certainly malloc contention (since threads share memory space). Each of my subtasks calls malloc more than a million times even for an average run. These are mostly dynamic allocations of vectors and matrices as well as smaller numbers of lists, sets and maps. My previous experience with Carbon suggests that tasks should work a lot better albeit with more programming effort. I'm close to finding out whether that is true in Cocoa. -- Mike McLaughlin _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
