From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 24 12:00:09 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9383D16A401; Fri, 24 Mar 2006 12:00:09 +0000 (UTC) (envelope-from kaakun@highway.ne.jp) Received: from mx.highway.ne.jp (pip7.gate01.com [61.122.117.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21EDC43D46; Fri, 24 Mar 2006 12:00:08 +0000 (GMT) (envelope-from kaakun@highway.ne.jp) Received: from [219.0.96.106] (helo=[192.168.11.17]) by pop12.isp.us-com.jp with esmtp (Mail 4.20) id 1FMkxa-0000l9-P1; Fri, 24 Mar 2006 21:00:06 +0900 Message-ID: <4423DDFA.3090504@highway.ne.jp> Date: Fri, 24 Mar 2006 20:54:34 +0900 From: Kazuaki Oda User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kostik Belousov References: <44215FE9.2070602@highway.ne.jp> <20060322174312.GB27116@deviant.kiev.zoral.com.ua> <20060322190725.GC27116@deviant.kiev.zoral.com.ua> <4421BA34.8040908@highway.ne.jp> <20060323105440.GD27116@deviant.kiev.zoral.com.ua> <20060324084834.GE27116@deviant.kiev.zoral.com.ua> In-Reply-To: <20060324084834.GE27116@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-threads@freebsd.org Subject: Re: [patch] Re: dlopen() and dlclose() are not MT-safe? YES, esp. for libthr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2006 12:00:09 -0000 Kostik Belousov wrote: > I did understand the purpose of the thread mask code in > libexec/rtld/rtld_lock.c, or, more precisely, the condition where this code > works (for the context, see the mails with same subject on freebsd-hackers). > > Look, that code assumes that blocking async signals would stop thread > scheduler from doing preemption of the current thread. This works > for libc_r, but fails in libpthread and libthr cases. libpthread provides > implementation of the locks for rtld. But libthr does not ! > > As result, rtld exhibit races when used with libthr. In other words, > libthr needs code to do proper locking. > > Do you agree ? Does somebody already planned to do this work ? > > Best regards, > Kostik Belousov I'm a bit confused. Do you mean the following? * The current implementation of rtld has a problem both with libpthread and libthr. It works only with libc_r. * In libpthread case, the problem goes away if we modify rtld code. * In libthr case, in addition to above, we must modify libthr code to provide implementation of the locks for rtld. right? -- Kazuaki Oda