From owner-freebsd-threads@FreeBSD.ORG Wed Apr 16 16:29:13 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAF4637B401; Wed, 16 Apr 2003 16:29:13 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33ACA43FE0; Wed, 16 Apr 2003 16:29:12 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from tiger (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with SMTP id h3GNTAUp096888; Wed, 16 Apr 2003 16:29:11 -0700 (PDT) (envelope-from davidxu@freebsd.org) Message-ID: <004c01c30470$9e36ddf0$0701a8c0@tiger> From: "David Xu" To: "Daniel Eischen" References: Date: Thu, 17 Apr 2003 07:33:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Xu List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2003 23:29:14 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Thursday, April 17, 2003 5:05 AM Subject: Re: libpthread patch > There's a new patch available at: >=20 > http://people.freebsd.org/~deischen/kse/libpthread.diffs >=20 > This passes all the ACE tests that libc_r passes, with the > exception of Cached_Conn_Test. >=20 > It also seems to work with KDE, konqueror, kwrite, kmail, etc. > I don't have mozilla built (and am dreading trying to), but > it would be interesting to see if it works with that. >=20 Cool! > If no-one has any objections, I'd like to commit this > soon. I'll let David review and comment to it first. >=20 > David, I didn't add critical regions to _thr_alloc() and > _thr_free(). I think that whenever they are used, we > are already in a critical region or operating on an upcall. >=20 Hmm, I don't like to put malloc calling under critical section, it is better to put it under a lock, otherwise this would cause dead=20 lock. suppose that an user thread is calling malloc(), and heap manager got malloc spinlock, then it does somethings and the thread is preempted by upcall from kernel, now UTS switches to another thread, that thread starts to call pthread_create, so UTS kernel enters a critical region = first, and calls malloc, this would cause dead lock, because UTS is under = critical region and no context switch could happen. Also I don't like thr_free under critical region, I think a GC thread is = still needed to recycle zombie thread and free extra memory, UTS kernel=20 should't be blocked by user thread. Despite this, I think the patch = should be committed.=20 David Xu > --=20 > Dan Eischen