From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22501 invoked by alias); 20 Sep 2004 19:50:25 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 22480 invoked from network); 20 Sep 2004 19:50:24 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org with SMTP; 20 Sep 2004 19:50:24 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id AF0B2357B; Mon, 20 Sep 2004 12:50:23 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.11/8.12.9) with ESMTP id i8KJoKrC015717; Mon, 20 Sep 2004 12:50:21 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.11/8.12.11/Submit) id i8KJoIJb015512; Mon, 20 Sep 2004 12:50:18 -0700 Date: Mon, 20 Sep 2004 19:50:00 -0000 Message-Id: <200409201950.i8KJoIJb015512@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Ulrich Drepper Cc: GNU libc hacker Subject: Re: setXid In-Reply-To: Ulrich Drepper's message of Monday, 20 September 2004 12:29:28 -0700 <414F2F98.9020905@redhat.com> Emacs: more boundary conditions than the Middle East. X-SW-Source: 2004-09/txt/msg00076.txt.bz2 > > I have never been in favor of a per-thread ID extension. > > They definitely want to preserve this and therefore any kernel solution > is as nonatomic as the userlevel implementation. (not my analysis). Like I said, they haven't been presented with an implementation yet. What I would propose would allow such an extension and also implement correct semantics when you are not using it. It's pointless to speculate about what others would or wouldn't say in circumstances that don't exist yet. > I think this is as good as we'll get it any time soon (or ever). Assuming you are talking about the simulation of almost correct semantics, that may be. My point about that was that we should make sure that people are aware of the "almost" and what it means. You did not respond at all to my objection to your glibc extension functions. Please say something about how you intend these to be acceptable features. As they stand, it's necessary for me to absolutely refuse to cooperate with their inclusion in glibc, and warn people away from using nscd as it is. Let's talk about what features we really do want, and about getting them fully specified and securely implemented. Thanks, Roland