I'm not 100% sure but I think that your child process inherits or can be made to inherit the parents mach ports. So the trick I envisage is
1> Parent create a right and make it inheritable (?)
2> Parent calls fork
3> Parent waits on a message
4> Calls exec with an argument of the inherited port id in hex I'd guess
and rendezvous can not happen
This seems pretty reliable, if ports can be inherited across a fork() which is a big if.
Finally if it doesn't work I know for a fact that it will work with unix-domain sockets.
On 2009-11-19, at 2: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.
> 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?
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