September 2009 - Darwin-dev

Re: Error when compiling blocks code in Snow Leopard
by Greg Parker 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com % cat test.cc class Foo { void Bar() { ^{ int i; }; } }; % c++ test.cc test.cc: In function 'void __Bar_block_invoke_1(void*)': test.cc:3: error: 'int Foo::i' is not a static member of 'class Foo' -- Greg Parker gparker(a)apple.com Runtime Wrangler _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Sep 3, 2009, at 1:40 PM, Terry Lambert wrote: The C++ standard limits the scope of variables declared like you are declaring 'i' (as a for-init-statement, technically) to the for itself, rather than extending to the end of the enclosing scope. This is a standards related change in behaviour from traditional C++/ g++, which, while not permitted by the standard, is how old compilers tended to be implemented, not having an explicit indicator for interior scope ends in their parse tree representation. There's nothing wrong with his `for` scope here; he didn't use `i` at all, much less use it out of scope. A block-local variable in a C++ method fails the same way with no loop at all: <rdar://problem/6499343> 10A241: Impossible to have Block local vars in C++ within a method declaration This email sent to site_archiver(a)lists.apple.com

1 0

Re: Error when compiling blocks code in Snow Leopard
by Terry Lambert 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry Hi, class Foo { void Bar() { dispatch_block_t b = ^{ for (int i = 0; i < 10; i++) { } }; } }; The same blocks definition compiles as pure C : void Bar() { dispatch_block_t b = ^{ for (int i = 0; i < 10; i++) { } }; } Thanks. Stéphane Letz _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… The C++ standard limits the scope of variables declared like you are declaring 'i' (as a for-init-statement, technically) to the for itself, rather than extending to the end of the enclosing scope. This is a standards related change in behaviour from traditional C++/g++, which, while not permitted by the standard, is how old compilers tended to be implemented, not having an explicit indicator for interior scope ends in their parse tree representation. You will get the same behavior for the C compiler, were you to specify the -ffor-scope option. Obviously, block scopes are asynchronous, and have to persist to the end of the enclosing scope, so the variables you use in them have to do so as well. On Sep 3, 2009, at 2:21 AM, Stéphane Letz wrote: We are experimenting with blocks in Snow Leopard and have the following error when compiling C++ code: test.cpp: In function ‘void __Bar_block_invoke_22(void*)’: test.cpp:1206: error: ‘int Foo::i’ is not a static member of ‘struct Foo’ test.cpp:1206: error: ‘i’ was not declared in this scope test: *** [all] Error 1 Are they any limitation for use of local variables in blocks when compiled in C++? This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Find argument passed to running process
by Terry Lambert 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Sep 3, 2009, at 3:14 AM, Nico Schmidt <lists(a)nschmidt.name> wrote: On 03.09.2009, at 05:11, Michael Smith wrote: On the subject of procfs; folks, you are trying to solve the wrong problem. Adding another access method absent a sensible schema does nothing to address the basic problem. How would you address the basic problem? I actually do not see a statement of the problem you are attempting to solve, beyond "I don't have an API for XYZ". Unless you have a specific, concrete application in mind for the API you are requesting, you are just asking people other than yourself to do work because you might need an API for XYZ some day. FWIW: My personal approach has always been to not need to ask the system for the information in the first place, because I already have it. The justification for a detailed synchronus arbitrary process status API that won't change for the next decade generally boils down to one of the following: (1) the information is for status reporting; solution: wrap a system utility like ps (2) the information is something the process being inspected wants published; solution: so have the process publish it, either procedurally via IPC or in /var/run (3) the information is something the parent wants published about one of its children; solution: the parent can publish it (see #2) (4) the information is something the parent needs later; solution: remember it, you're the one who started the process in the first place... you don't need an API just because you are too lazy to remember it (5) the information is not security sensitive, and some process would like to have it because it's overly nosy; solution: either quit being nosy or use a system tool (see #1), or use public self/parent published information if it exists (see #2) (6) the information is security sensitive, and some privileged process would like to have it because it's overly nosy (see #5; trust the tools to recognize privilege) (7) the information is security sensitive, and some unprivileged process would like to have it because it's overly nosy; solution: obtain privilege legitimately (see #6), or go away empty handed because leaving you empty handed was a design goal (behaves correctly) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Find argument passed to running process
by Nico Schmidt 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 03.09.2009, at 05:11, Michael Smith wrote: On Sep 2, 2009, at 12:04 PM, darwin-dev-request(a)lists.apple.com wrote: Why do you think you want to do this? How would you address the basic problem? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Thanks all. My internet connection was down so I could not reply. Solution suggested by Terry using popen() and read argument is right, but I want to implement without using shell or system() or any other script. Please understand that when you are responding to Terry, you are talking to one of the small number of individuals tasked with maintaining this particular interface. His word on correct usage is as close to final as anything you're going to get. Please also understand that the information returned by ps for a process' arguments is not guaranteed to be correct or parseable. If you require a contract with the calling task, you must arrange for the calling task to save the argument information somewhere else. Nico misses the point when complaining that the output is not reliable; it is not meant to be a communcation channel, it is meant to be informative. I didn't mean to complain :). This was meant as an argument for an interface that *is* reliable. On the subject of procfs; folks, you are trying to solve the wrong problem. Adding another access method absent a sensible schema does nothing to address the basic problem. This email sent to site_archiver(a)lists.apple.com

1 0

Error when compiling blocks code in Snow Leopard
by Stéphane Letz 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, class Foo { void Bar() { dispatch_block_t b = ^{ for (int i = 0; i < 10; i++) { } }; } }; The same blocks definition compiles as pure C : void Bar() { dispatch_block_t b = ^{ for (int i = 0; i < 10; i++) { } }; } Thanks. Stéphane Letz _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… We are experimenting with blocks in Snow Leopard and have the following error when compiling C++ code: test.cpp: In function ‘void __Bar_block_invoke_22(void*)’: test.cpp:1206: error: ‘int Foo::i’ is not a static member of ‘struct Foo’ test.cpp:1206: error: ‘i’ was not declared in this scope test: *** [all] Error 1 Are they any limitation for use of local variables in blocks when compiled in C++? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Find argument passed to running process
by Michael Smith 03 Sep '09

03 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Find argument passed to running process
by lists 02 Sep '09

02 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 02.09.2009, at 21:40, Terry Lambert wrote: To actually answer the question, look at the source code for "ps": <http://developer.apple.com/mac/library/qa/qa2001/qa1123.html> Do you really not understand the concept of a sustainable binary API? For example, a commercial application sold by your employer. Terry, Nico _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Sep 2, 2009, at 2:37 AM, Nico Schmidt <lists(a)nschmidt.name> wrote: On 02.09.2009, at 10:07, Terry Lambert wrote: On Sep 1, 2009, at 9:38 PM, Stephen J. Butler wrote: On Tue, Sep 1, 2009 at 9:55 AM, Rakesh Singhal<rakesh.singhal(a)gmail.com > wrote: I can find pid for any running process using code given here http://developer.apple.com/mac/library/qa/qa2001/qa1123.html. But I want to find the arguments passed to this running process, when it was launched. I checked the kinfo_proc structure but I could not find any thing related to arguments. <http://www.opensource.apple.com/source/adv_cmds/adv_cmds-119/ps.tproj/ps.c > It calls sysctl with { CTL_KERN, KERN_PROC, what, flags } (look a little higher up for what gets stuffed in those vars). From the result, it then looks at "kp[i]->kp_proc->p_comm" (saveuser function). "The UNIX Programming FAQ lists a number of alternative ways to do this. Of these, the only approach that works on Mac OS X is exec'ing the ps command line tool. exec'ing ps will require parsing the tool's output and will not use system resources as efficiently as Listing 1." ...on the other hand, the ps method is more likely to continue to work in future versions of the OS. Also note that qa is 7 or 8 years old, based on how you read the dates. The problem with parsing the output of ps is that it only works with the most harmless arguments. If a command line argument contains funny characters like a line feed for example it will show up as "^M" in ps's output. I always wondered why there is no way to get the information ps delivers in a library function. Parsing output may have worked in the days where a Unix user would not even imagine putting anything but printable non-whitespace characters in a file name. The answer is because it requires committing to an API which, for binary compatibility reasons, can't be changed thereafter for close to a decade without breaking one or more commercial applications. When you do that, it constrains your underlying implementation details, and that prevents performance improvements and other positive changes to architecture. Publishing an API without considering very long term consequences is worse than publishing no API. For example, consider that procfs exposes a flat numeric PID namespace, which means that if some important product starts relying on it, until that product both recognizes a need to get off that API, and has sufficient time to migrate its customers to a version which actually gets off that API, whatever paradigm the OS comes up with for representing things after that now has to be capable of being jammed, however inefficiently, into a flat numeric namespace. Or the application breaks. Now multiply this problem by the number of applications vendors out there. How likely are they to all move off a "bad" interface within say 2 years of it being deprecated? 5? How do you keep new code, written either by people who don't know any better, or who know better but are up against a deadline and willing to do dirty tricks to meet it, from using the interface? This is a common problem with all data interfaces, like procfs, which was not well thought out in terms of long term consequences. It doesn't matter if you are talking about a data iterator interface like opendir/readdir/closedir applied against a schelling point, like the known path to the location in a procfs where the directory entries represent a list of integers-as-ASCII strings in a flat numeric namespace, or it's something else. Like jamming a PID into the third 32 bit integer value in an OID tuple in that sysctl (above) that was suggested in answer to this question, thus capping the systems future PID values because of the OID value field size. Or deciding because an interface is protected from access by non- root processes that you can cast a pointer to an int, then pass it back as a token and cast it back into a pointer, "because everyone knows pointers and integers are the same size". Data interfaces are a bad idea. Procedural interfaces are only barely better, since you can codify constraints into them with bad API design, too. Don't get me started on early systems with 32 bit off_t types as the third argument to the read and write calls, as one example. But at least a procedural interface, even an iterator, doesn't _have_ to expose underlying structure, the way opendir() does when used against another data interface (e.g. the exposed file system namespace of a procfs, for example, with a well known layout that can't change after code starts to depend on it). So far there is no compelling business reasons I'm aware of to design a sustainable API for this particular information, other than talking to the system utilities which have their data interfaces more or less frozen in place by international standards. On the other hand, there are some pretty compelling engineering reasons to *not* do it, starting with the constraints it would inevitibly place on engineers trying to make changes later. -- Terry thanks for your comprehensive answer. I fully understand the concerns. They should not keep anyone from thinking about how it could be done though. All concepts needed for an API like this are fixed at one place or another already. The pid_t type is used in some syscalls. And the exec [lv][pe]? type calls are in existence since 1970 and fix arguments to programs to be some sort of strings. So an API like get_proc_args (pid_t pid, const char*** args, int* numArguments) does not seem to change these constraints much. Maybe you are right on the last point about there not being a compelling business reason. Maybe the original poster could elaborate a bit on why he needs the information. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Find argument passed to running process
by Terry Lambert 02 Sep '09

02 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com To actually answer the question, look at the source code for "ps": <http://developer.apple.com/mac/library/qa/qa2001/qa1123.html> Do you really not understand the concept of a sustainable binary API? For example, a commercial application sold by your employer. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Sep 2, 2009, at 2:37 AM, Nico Schmidt <lists(a)nschmidt.name> wrote: On 02.09.2009, at 10:07, Terry Lambert wrote: On Sep 1, 2009, at 9:38 PM, Stephen J. Butler wrote: On Tue, Sep 1, 2009 at 9:55 AM, Rakesh Singhal<rakesh.singhal(a)gmail.com > wrote: I can find pid for any running process using code given here http://developer.apple.com/mac/library/qa/qa2001/qa1123.html. But I want to find the arguments passed to this running process, when it was launched. I checked the kinfo_proc structure but I could not find any thing related to arguments. <http://www.opensource.apple.com/source/adv_cmds/adv_cmds-119/ps.tproj/ps.c > It calls sysctl with { CTL_KERN, KERN_PROC, what, flags } (look a little higher up for what gets stuffed in those vars). From the result, it then looks at "kp[i]->kp_proc->p_comm" (saveuser function). "The UNIX Programming FAQ lists a number of alternative ways to do this. Of these, the only approach that works on Mac OS X is exec'ing the ps command line tool. exec'ing ps will require parsing the tool's output and will not use system resources as efficiently as Listing 1." ...on the other hand, the ps method is more likely to continue to work in future versions of the OS. Also note that qa is 7 or 8 years old, based on how you read the dates. The problem with parsing the output of ps is that it only works with the most harmless arguments. If a command line argument contains funny characters like a line feed for example it will show up as "^M" in ps's output. I always wondered why there is no way to get the information ps delivers in a library function. Parsing output may have worked in the days where a Unix user would not even imagine putting anything but printable non-whitespace characters in a file name. The answer is because it requires committing to an API which, for binary compatibility reasons, can't be changed thereafter for close to a decade without breaking one or more commercial applications. When you do that, it constrains your underlying implementation details, and that prevents performance improvements and other positive changes to architecture. Publishing an API without considering very long term consequences is worse than publishing no API. For example, consider that procfs exposes a flat numeric PID namespace, which means that if some important product starts relying on it, until that product both recognizes a need to get off that API, and has sufficient time to migrate its customers to a version which actually gets off that API, whatever paradigm the OS comes up with for representing things after that now has to be capable of being jammed, however inefficiently, into a flat numeric namespace. Or the application breaks. Now multiply this problem by the number of applications vendors out there. How likely are they to all move off a "bad" interface within say 2 years of it being deprecated? 5? How do you keep new code, written either by people who don't know any better, or who know better but are up against a deadline and willing to do dirty tricks to meet it, from using the interface? This is a common problem with all data interfaces, like procfs, which was not well thought out in terms of long term consequences. It doesn't matter if you are talking about a data iterator interface like opendir/readdir/closedir applied against a schelling point, like the known path to the location in a procfs where the directory entries represent a list of integers-as-ASCII strings in a flat numeric namespace, or it's something else. Like jamming a PID into the third 32 bit integer value in an OID tuple in that sysctl (above) that was suggested in answer to this question, thus capping the systems future PID values because of the OID value field size. Or deciding because an interface is protected from access by non-root processes that you can cast a pointer to an int, then pass it back as a token and cast it back into a pointer, "because everyone knows pointers and integers are the same size". Data interfaces are a bad idea. Procedural interfaces are only barely better, since you can codify constraints into them with bad API design, too. Don't get me started on early systems with 32 bit off_t types as the third argument to the read and write calls, as one example. But at least a procedural interface, even an iterator, doesn't _have_ to expose underlying structure, the way opendir() does when used against another data interface (e.g. the exposed file system namespace of a procfs, for example, with a well known layout that can't change after code starts to depend on it). So far there is no compelling business reasons I'm aware of to design a sustainable API for this particular information, other than talking to the system utilities which have their data interfaces more or less frozen in place by international standards. On the other hand, there are some pretty compelling engineering reasons to *not* do it, starting with the constraints it would inevitibly place on engineers trying to make changes later. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Find argument passed to running process
by Jean-Daniel Dupas 02 Sep '09

02 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Find argument passed to running process
by Rakesh Singhal 02 Sep '09

02 Sep '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=/KleTbH0seMwUMGEjzh+N41Eg3mr3qwYePnuuAZayTw=; b=XisSNryxdA16kH07QBKeGzvuXbQ+Y/7r8R2OD/jyvp0IJ5SpvOM2mbxJ66SL18SRgt pLnrKQQMz7/QKeQBS+NgZpfpfv755uasuHUCCraY4jtsB4HgSRq0BPQNuXkEJcNZDV1h ExAECnHWECq4JGM8p8MFdO4HngeBar2/vYYJI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t3jxXH92Yiae/ESaYR4wO71Y4QDB+Vh+bfCIkGwa9PEbiK0se/nwW782RgymZFUeQE 9GEUiCGKB4RKSCxpkFNIzREM9lK68YkcQj2hecAIEnd1O2//ak5fjit0Ljr+gt+nLoi4 srIq/ko5U2nXgxTEt3tWjC8Ywa6WUw/mQyQc8= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0