From owner-freebsd-threads@FreeBSD.ORG Wed Apr 16 18:35:16 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 2D34737B401 for ; Wed, 16 Apr 2003 18:35:16 -0700 (PDT) Received: from exchhz01.viatech.com.cn (ip-167-164-97-218.anlai.com [218.97.164.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEE9D43F85 for ; Wed, 16 Apr 2003 18:35:13 -0700 (PDT) (envelope-from davidxu@freebsd.org) Received: from davidw2k (ip-240-1-168-192.rev.dyxnet.com [192.168.1.240]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HLDQQQ3R; Thu, 17 Apr 2003 09:20:44 +0800 Message-ID: <001501c30481$d1d7a9d0$f001a8c0@davidw2k> From: "David Xu" To: "Daniel Eischen" References: Date: Thu, 17 Apr 2003 09:36:51 +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.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 01:35:16 -0000 ----- Original Message -----=20 From: "Daniel Eischen" To: "David Xu" Cc: Sent: Thursday, April 17, 2003 7:46 AM Subject: Re: libpthread patch > On Thu, 17 Apr 2003, David Xu wrote: >=20 > >=20 > > ----- Original Message -----=20 > > From: "Daniel Eischen" > > To: "David Xu" > > Cc: > > Sent: Thursday, April 17, 2003 5:05 AM > > Subject: Re: libpthread patch > >=20 > >=20 > > > 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 > >=20 > > Cool! > >=20 > > > 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 > >=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 = > > 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. >=20 > Hmm, I see what you mean. We could put spinlock in critical region > and that may solve the problem, but I eventually want to see spinlocks > go away and replace the very few that we have in libc with mutexes. >=20 > > 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 >=20 > I'll work on adding the GC thread back in. I really wanted to > get rid of it so that the KSE can exit when threadcount =3D=3D 0, > but now we've got to make allowances for the extra thread > in the main KSEG. >=20 If you don't want to use GC thread, you can free extra zoombie threads in thr_alloc(), everytime when thr_alloc is called, if it finds there is too many zoombie threads, free them. > Keep looking at the patch for anything else you might see. > We still need a way to deliver signals and look for async > cancel points in CPU-bound threads. The attempt to add a > signal frame with signalcontext() doesn't seem to work > which is why it is commented out. >=20 I will look. > --=20 > Dan Eischen