Date: Tue, 30 Oct 2007 09:44:43 +0100 From: Kris Kennaway <kris@FreeBSD.org> To: David Xu <davidxu@FreeBSD.org> Cc: Daniel Eischen <deischen@FreeBSD.org>, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libthr/thread thr_mutex.c src/lib/libkse/thread thr_mutex.c src/include pthread.h Message-ID: <4726EEFB.8030309@FreeBSD.org> In-Reply-To: <47269AD0.3080906@freebsd.org> References: <200710292101.l9TL1mAE049561@repoman.freebsd.org> <47268F17.1000106@freebsd.org> <Pine.GSO.4.64.0710292207140.19572@sea.ntplx.net> <47269AD0.3080906@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote: > Daniel Eischen wrote: >> On Tue, 30 Oct 2007, David Xu wrote: >> >>> I am not sure PTHREAD_MUTEX_ADAPTIVE_NP is a correct solution, in fact >>> I think this is Linux crap, shouldn't PTHREAD_PRIO_PROTECT and >>> PTHREAD_PRIO_INHERIT mutex be adaptivly spinned ? >>> also this commit does not change mutex_self_lock() to handle the >>> PTHREAD_MUTEX_ADAPTIVE_NP, what is the PTHREAD_MUTEX_ADAPTIVE_NP >>> definition when the mutex is already locked by the currect thread ? >>> deadlock or return error code ? >> >> >> I tend to agree with the "Linux crap" comment, but I hesitate >> to use those words considering the recent sensor framework >> incident ;-) >> > > Isn't this commit an incident too ? :-) if it is not, then > we should retire from FreeBSD now, as two thread library > maintainers were bypassed. Hi David, I'm honestly a bit surprised to hear that you consider yourself to be the maintainer of this code, because while you have certainly worked heavily on it in the past, I have sent several mails to you over the past year or so raising various problems and ideas I have encountered in the libthr and related code while working on performance tuning, and you have declined to reply to many of them, or to participate in the ongoing optimization work. That being said, it's only an "incident" if you choose to be offended by the commit. I'd recommend instead focusing on the technical issues, specifically the fact that there does not exist a better alternative way to do this at the present date. I have discussed the reasons why in my previous emails (in particular, an env variable is inappropriate), so please refer to those specifc points in formulating any further reply. Jeff, Attilio and I have ideas about how we might be able to improve the libthr and umtx code going forward, so we'd be delighted to have your help in working on them. Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4726EEFB.8030309>