Date: Thu, 17 Apr 2003 07:33:42 +0800 From: "David Xu" <davidxu@freebsd.org> To: "Daniel Eischen" <eischen@pcnet1.pcnet.com> Cc: freebsd-threads@freebsd.org Subject: Re: libpthread patch Message-ID: <004c01c30470$9e36ddf0$0701a8c0@tiger> References: <Pine.GSO.4.10.10304161701160.26800-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----=20 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: >=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004c01c30470$9e36ddf0$0701a8c0>