Date: Wed, 16 Apr 2003 19:46:02 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: David Xu <davidxu@viatech.com.cn> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <Pine.GSO.4.10.10304161938070.18792-100000@pcnet1.pcnet.com> In-Reply-To: <004c01c30470$9e36ddf0$0701a8c0@tiger>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Apr 2003, David Xu wrote: > > ----- Original Message ----- > From: "Daniel Eischen" <eischen@pcnet1.pcnet.com> > To: "David Xu" <davidxu@freebsd.org> > Cc: <freebsd-threads@freebsd.org> > Sent: Thursday, April 17, 2003 5:05 AM > Subject: Re: libpthread patch > > > > There's a new patch available at: > > > > http://people.freebsd.org/~deischen/kse/libpthread.diffs > > > > This passes all the ACE tests that libc_r passes, with the > > exception of Cached_Conn_Test. > > > > 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. > > > > Cool! > > > If no-one has any objections, I'd like to commit this > > soon. I'll let David review and comment to it first. > > > > 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. > > > > 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. 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. > 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 > should't be blocked by user thread. Despite this, I think the patch should > be committed. 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 == 0, but now we've got to make allowances for the extra thread in the main KSEG. 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. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304161938070.18792-100000>