Re: Mach Bootstrap_create_server, "server_command" parameter
Re: Mach Bootstrap_create_server, "server_command" parameter
- Subject: Re: Mach Bootstrap_create_server, "server_command" parameter
- From: Michael Prenez-Isbell <email@hidden>
- Date: Tue, 17 Feb 2009 16:59:40 -0500
- Thread-topic: Mach Bootstrap_create_server, "server_command" parameter
Can NSMachPort be used for IPC? I don't see a way to make an NSMachPort
local or remote. It seems as if you already have to have a mach port to use
it.
If this is possible, is there a coding example?
Or is CFMessagePort a better way to go?
Michael
On 2/17/09 9:10 AM, "Quinn" <email@hidden> wrote:
> At 5:50 -0500 17/2/09, Michael Prenez-Isbell wrote:
>> Not sure what I think about actually eliminating an API in favor of a config
>> oriented approach. Why not just document the API properly. Nothing wrong
>> with the API and it seems to me it's more coherent with the rest of the Mach
>> API. Just my two cents.
>
> This stuff makes a lot more sense once you grok the launchd
> philosophy. Specifically, launchd is all about launching on demand.
> That is, rather than some master script controlling how the system
> boots (/etc/rc, or its logically successors), launchd launches
> services on demand. It starts one master service (loginwindow) and
> then, as that service requests other services, it launches those
> services, and so on. This has a number of advantages:
>
> o system boot is lazy--only services that need to start get started
> o startup is inherently parallel
> o there's no need to maintain a master startup script
>
> However, for this to work launchd needs to know which services exist
> and how they get launched on demand. And that's what the
> configuration files are all about.
>
>> Just out of curiosity, is there some historical reason why there is so
>> little real example code out there on the web for the mach stuff.
>
> It's not just a historical reason. In general Apple recommends that
> developers avoid using Mach APIs directly if they can. This is
> because the Mach APIs are the lowest-level interface to the kernel,
> so they are more likely to be affected by changes to the underlying
> kernel. Also, the behaviour of the Mach APIs is not standardised,
> which makes it harder for us to do the right thing binary
> compatibility-wise.
>
> To encourage folks to avoid Mach, we don't document them well, and we
> don't ship formal sample code for them, except in situations where a
> Mach API is the only good solution to a particular problem.
>
> It's also important to realise that we don't have enough resources to
> document all the APIs that we actively /want/ developers to use (VFS
> KPI documentation, I'm looking at you!). So the fact that the Mach
> APIs are not properly documented isn't saying too much (-:
>
> Just to be clear, the Mach APIs are /supported/. We ship the headers
> as part of the public SDK, DTS answers questions about them, and
> kernel engineering does its best to avoid breaking them. However, if
> there is a good alternative, I'd recommend that you use it. [Insert
> Quinn's standard plug for UNIX domain sockets (-: ]
>
> Share and Enjoy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden