From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: dbailey27@ameritech.net Cc: torvalds@osdl.org, 9fans@cse.psu.edu Subject: Re: [9fans] Re: Threads: Sewing badges of honor onto a Kernel Message-ID: <20040227090651.C22848@cackle.proxima.alt.za> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from dbailey27@ameritech.net on Fri, Feb 27, 2004 at 01:48:09AM -0500 Date: Fri, 27 Feb 2004 09:06:52 +0200 Topicbox-Message-UUID: fd7b143e-eacc-11e9-9e20-41e7f4b1d025 On Fri, Feb 27, 2004 at 01:48:09AM -0500, dbailey27@ameritech.net wrote: > > > Anything that accesses any process arguments would access the stack of the > > original thread. > > I'm not sure I can agree here. Arguments are not meant for the scope of an > entire process, but for the initialization of a program's state. In a program that > [ ... ] Not only. Presumably, the stack is duplicated on rfork(2) which means that reading the arguments is OK, writing them would be a problem. But just because the arguments can be changed does not mean that it can't be deprecated in the case of threads. ++L PS: I do think this particular one is a quibble, though. My choice would be along the lines of: "having made choice "A", is there a mechanism to implement choice "B" from within it?" If there is, then only efficiency criteria can be used to select "A" over "B". If there isn't, then either the reverse applies in which case "B" is the obvious contender, or the two are distinct solutions, each requiring implementation.