site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi Terry, Am 12.12.2007 um 03:27 schrieb Terry Lambert: Hi! -- 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 12, 2007, at 12:21 AM, Mike Fischer <mike_fischer@mac.com> wrote: On Dec 11, 2007, at 7:26 AM, Mike Fischer wrote: For some reason I can't seem to get getrusage(2) to work the way I expect it to under 10.4.11 on a PPC G5 machine (haven't tested on other machines). I expected the memory related fields to show values other than 0 which more or less correlate with the actual memory usage of the application. But what I am seeing is values of 0 only in each of these fields (ru_maxrss, ru_ixrss, ru_idrss, ru_isrss). Probably I'm doing something wrong, but what? Most of the information you are requesting in Mac information, and you are requesting it using a BSD API. Generally I don't see anything wrong with that. Why wouldn't I call BSD APIs in a command line tool? (Also your sentence structure is not entirely clear to me so I may be missing some of the meaning here?) Sorry, iPhone correction-itis. "is Mach information". The BSD portion of the kernel does not maintain separate, parallel state information for this Mach data, as doing so would be prohibitively expensive. As a result, the only way to get the information is to post-process the corresponding Mach data, and to avoid repeated expense, this is only done after process termination, to provide totals, rather than a running tally. The BSD API idea of the information will not be updated until the process exits (see xnu/bsd/kern/kern_exit.c:proc_exit()). Err, in that case how would the call ever work with the given option RUSAGE_SELF? Generally, it would not. Our command line (and GUI) performance tools tend to use Mach, rather than BSD, APIs for reporting most information like this, if that information needs to be collected at runtim, rather than on a child process. Seems like a chicken and egg problem to me: the info is updated when the process exits but since the process has exited it can't call getrusage any more. At the very least the man page could be a bit more clear about this. File a bug; most likely we will change the man page to deprecate use of this call, and point you at our performance tools instead. If you want this information while the process is running, you're going to need link against the whole kernel and use unsupported APIs. No thanks, I don't want the info that badly ;-) I was just experimenting to see if I could access similar values to what top(1) or Activity Monitor report inside my application. And since they can do this while my app is running I thought the process itself should be able to as well. These tools use a combination of APIs, SPIs, and unstable interfaces which can change from release to release, even in software updates. The reason it's ok for us to do this is that when we modify the means of getting the information, we are able to modify system supplied tools in lock-step with kernel modifications, so the tools keep working. This is the primary reason I suggested a popen of a "ps -o<list of fields> -<scoping options>" would probably be a more or less portable way of getting state information on processes. At least you know that to keep certification, we have to keep supporting the options POSIX requires, and if we change the way the ps program obtains information, we'll change the ps program itself in lockstep with the kernel/line changes. Needless to say, this will end up being rather expensive, which is why we don't export them via BSD in the first place. Yeah, that makes sense. But given the documentation of getrusage my expectations where different. Should I file a bug? If so, against getrusage You can; the most likely response, as noted above, will be to modify the man page to tell you not to use it. I understand people wanting to write their own performance tools, but people who do this also need to understand that doing so will likely tie them to the same constraints Apple has with regard to using SPIs and unstable interfaces. This translates to them potentially having to recompile their tools on each software update, just like we frequently have to do, to keep them working, unless they wrap out tools. This email sent to site_archiver@lists.apple.com