On Nov 18, 2009, at 7:02 AM, Uli Kusterer wrote:
> On 17.11.2009, at 20:27, Damien Sorresso wrote:
>>> Can you expand on what you're trying to do?
> We have a 32 bit application that needs to create a 64 bit process to do processor intensive tasks and communicate with the main application typically hundreds of times per second, depending on the number of tasks. Passing shared memory objects and rights is also involved. Performance is critical, AppleEvents, distributed objects etc. seem too slow.
>> The recommended replacement is to have two launchd jobs, one which advertises a service with a well-known name in the bootstrap namespace.
> We don't have a well-known name, that would have been the case for suggestion #2 in bootstrap.h, however this is not the case. In this case the name is dynamic and has no general purpose use for the system, in other words scenario #3 applies.
Just because a service doesn't have general purpose use for the system doesn't mean you should not register it with a well-known name. Privileged helper tools that are tied to specific applications also don't have general use for the system, but their MachService names (if they have them) are still registered with launchd and bootstrap_check_in().
Registering services with well-known names is part of launchd's on-demand model.
> To rephrase the original question for clarification:
> Is recommendation #3 in bootstrap.h regarding "sending a Mach send-right directly" technically accurate and valid?
> If yes, how does it envision sending a Mach send-right directly given the very fundamental principles and security constraints of Mach IPC?
What "fundamental principles and security constraints" are you referring to? In Mach, holding a right to a port also means that you can transmit that right to another process if you want. This is fundamental to Mach and how Mac OS X works. We fling rights around the system all the time; that's what bootstrap_check_in() and bootstrap_look_up() are for.
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden