Re: Talking to the Dock
Re: Talking to the Dock
- Subject: Re: Talking to the Dock
- From: "Neil A. Van Note" <email@hidden>
- Date: Wed, 30 Jul 2003 14:12:33 -0400
Just some observations,
sysctl is a fairly simple API, and in my tests, averages a 40:1
performance advantage against executing a focused ps via. popen. I didn't
bother benching against a piped NSTask (which is virtually the same thing)
after noting the above difference.
Also, The sysctl API for reading the process list does not seem to be
effected by the current users privileges, at least while tracking down the
Dock from a regular user account.
After some further testing, it would seem the sysctl API does bring back
a *full* process list irrespective of the executing current user account (at
least the ones I tested) without the calling application having to authorize
itself as root. This is while using a 3 element MIB (Management Information
Base) of CTL_KERN, KERN_PROC, KERN_PROC_ALL.
Regards,
Neil A. Van Note
On 7/29/03 11:12 AM, "Sailor Quasar" <email@hidden> wrote:
>
On Tuesday, July 29, 2003, at 10:46 AM, M. Uli Kusterer wrote:
>
>> I'm reasonably sure there's no Cocoa wrapper around it, but it would
>
>> probably be simpler to use NSTask to shell out to the 'ps' command.
>
>> sysctl() is a complicated set of multi-level options and data
>
>> structures, but the output of ps can be parsed easily since it's
>
>> possible to request specific information from ps and the output can
>
>> be distilled further using pipes into awk and grep. The only reason
>
>> to use sysctl() directly would be if speed is critical to the code in
>
>> question.
>
> Maybe I spend too much time implementing parsers and have thus grown
>
> allergic to them, but I generally find it much more convenient (and
>
> reliable) to call "real" APIs than to call through to a command-line
>
> tool.
>
>
To a point, yes. It's certainly much easier to call gethostbyname()
>
than to shell out to 'dig' and parse it's output. On the other hand,
>
sysctl() in terms of the process list is a rather involved operation,
>
including authorizing yourself as root if you want the full process
>
list instead of only the things the current user started. 'ps' is
>
already known to be safe and is setuid root.
>
>
> Not to mention that I'm of the faction that says that speed is always
>
> critical in application software, at least where it doesn't make the
>
> code unreadable. I wouldn't switch to inline-assembly if it's not
>
> really necessary, but otherwise I see no point in needlessly hogging
>
> the user's CPU needlessly. I have enough applications that hog the CPU
>
> excessively and without which I can't do. So chances are that if your
>
> app needs more CPU than is warranted by its function, I'll throw it
>
> away.
>
>
I don't think there's been a computer since the beige G3's that would
>
take perceptibly longer to ps|awk|grep than to AuthServices|sysctl(). A
>
macroscopic difference at the CPU level can be quite microscopic in
>
realtime.
>
>
> But yes, if you don't care about subtle changes in the output of "top"
>
> or "ps" screwing up your parsing, and you enjoy writing parsers that
>
> take apart information that can be received already dissected from a
>
> system API, and you don't care about it taking a little longer, NSTask
>
> is a solution as well.
>
>
"Subtle changes" in the output of those commands would break a great
>
many more things than someone's use of NSTask. The output and options
>
of the BSD 'ps' command are well-known and long-standing. There have
>
been extensions, but never any that changed the basic structure of the
>
output. (Disclaimer: this is in my own knowledge only; someone more
>
versed in UNIX history may feel free to correct me :).
>
>
> But if you want to see an example of a parser that isn't good enough,
>
> check out the way PB doesn't report missing symbols. It simply says
>
> "build failed" and leaves you to look in the raw gcc output what
>
> actually went wrong...
>
>
That's Apple's sloppiness. I personally barely notice, since as a UNIX
>
junkie I'm always sifting through the raw build output anyway. I
>
recognize of course that some would be very put off by having to do
>
this (this is a shout-out to you, Larry! :). However, a little simple
>
care would easily prevent such a gross negligence.
>
>
On this same subject, I'm convinced Apple has no excuse for the bug you
>
mentioned. They've obviously learned how to pipe gcc's output into PB,
>
and the output of the ld subprocess is clearly defined and simple to
>
parse. At worst, they already added a great many extensions to gcc for
>
use of various mapfiles and such, if they were feeling really silly
>
they could have added another one to output an undefined symbol list.
>
Of course, on the flip side, I'm sure we'll all agree that PB is not a
>
finished product :).
>
>
> Cheers,
>
> M. Uli Kusterer
>
> ------------------------------------------------------------
>
> "The Witnesses of TeachText are everywhere..."
>
> http://www.zathras.de
>
>
-- Sailor Quasar, guardian of Leraz's memory
>
"A face of stone may hide a soul with the deepest Love of all"
>
Email: email@hidden
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.