From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23091 invoked by alias); 1 May 2004 09:38:02 -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 23070 invoked from network); 1 May 2004 09:38:02 -0000 Received: from unknown (HELO sunsite.ms.mff.cuni.cz) (195.113.15.26) by sources.redhat.com with SMTP; 1 May 2004 09:38:02 -0000 Received: from sunsite.ms.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8) with ESMTP id i417Ot3j029271; Sat, 1 May 2004 09:24:55 +0200 Received: (from jakub@localhost) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8/Submit) id i417OtPg029267; Sat, 1 May 2004 09:24:55 +0200 Date: Sat, 01 May 2004 09:38:00 -0000 From: Jakub Jelinek To: Wolfram Gloger Cc: libc-hacker@sources.redhat.com Subject: Re: [PATCH] Fix linuxthreads with pthread_attr_setstack{,addr} Message-ID: <20040501072454.GA5191@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <20040429141901.GR5191@sunsite.ms.mff.cuni.cz> <20040429143129.GS5191@sunsite.ms.mff.cuni.cz> <20040430171450.2358.qmail@md.dent.med.uni-muenchen.de> <20040430151958.GZ5191@sunsite.ms.mff.cuni.cz> <20040430180417.2588.qmail@md.dent.med.uni-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040430180417.2588.qmail@md.dent.med.uni-muenchen.de> User-Agent: Mutt/1.4i X-SW-Source: 2004-05/txt/msg00000.txt.bz2 On Fri, Apr 30, 2004 at 06:04:17PM -0000, Wolfram Gloger wrote: > Hi, > > > It is in pthread_join's RATIONALE: > > http://www.opengroup.org/onlinepubs/009695399/functions/pthread_join.html > > Interesting. AFAIC remember, this has changed from when I looked at > it in 2001. Although only in the "informative" section, I would > actually welcome such a guarantee, and think we should make it > possible to free application stacks after a return from > pthread_join(). Actually, the yesterday released TC2 clarifies user defined stacks and indeed a conforming application cannot free ever user defined stack once it has been used successfully in some pthread_create or SIGEV_THREAD notification. 2.9.8 is new in TC2: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_08 Jakub