site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Am 15.12.2008 um 12:11 schrieb Rakesh Singhal: Pardon me, but did you actually read the link? - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Dec 15, 2008, at 3:21 AM, Alexander von Below wrote: 2. Yes you are right, I can see in Activity Monitor but I want to find out the programatically. http://developer.apple.com/qa/qa2001/qa1123.html I see he's discovered that using ftok(0 is not going to buy him what he thought it would buy him, if he uses bundle-relative shared libraries for his application, rather than trying to install them in a system location, so he can do drag-installs. I expected that this would come up eventually in this thread. Please be aware that in using the sysctl API describe in this tech note, you will end up internally taking the funnel, which will stall other processes also using the API, which include but are not limited to, ps, ActivityMonitor, launchd, and others. In general, this will make everything pile up behind your process for as long as it's nosing around. If you can, get the information some other way, use it; Ideally, you would record the information in a file in /var/run named after the application, and from which it obtained it from its own bundle identifier. Note that there is no guarantee that this information will not become immediately invalid in any case, since the application can be moved/ removed out from under you after it's loaded, and realize that the p_comm field will only contain the short command name, and is limited to 16 characters and does not include the full path. When we create a process, we inform it of the path that was used to start it (so it can do bundle-relative things), but again, that information is subject to becoming stale (for example, as a result of installing an update while the process is running, you will get the path to the new bundle rather than the bundle of the running code, as the update replaces it). In general, there is no atomic/idempotent way to associate this information with a given running program, and what information there is regarding the full path is generally only known to the program itself (unless, of course it chooses to share it by, for example, writing the information out to a file in /var/run). This email sent to site_archiver@lists.apple.com