Date: Sun, 17 Apr 2011 16:35:05 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: hackers@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: puzzled: fork +libthr Message-ID: <4DAAEC89.1090103@FreeBSD.org> In-Reply-To: <4DA98197.8060104@FreeBSD.org> References: <4DA98197.8060104@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 16/04/2011 14:46 Andriy Gapon said the following: > > Guys, > > I am trying to debug this chromium issue: > http://trillian.chruetertee.ch/chromium/ticket/13 > Not sure SOCK_SEQPACKET mentioned in the ticket is an actual culprit, the > problem that interests me is that pthread_cond_wait() returns EPERM where it > shouldn't. That happens on stable/8. > > I compared ktrace of chromium on stable/8 and head. Startup traces are very > similar until execution gets to one particular place. At that place stable/8 > chromium executes pthread_cond_wait - I see _umtx_op(UMTX_OP_CV_WAIT) and that's > where EPERM is returned. On the other hand it seems that head chromium executes > something different at exactly the same place, perhaps sem_wait - I see > _umtx_op(UMTX_OP_WAIT_UINT_PRIVATE). So this is puzzle #1 for me why chromimum > build or run-time chooses a different thing to call/use at that place. OK, this was simple. This is because of the new userland condvar implementation in head. The call is the same pthread_cond_wait, just the different implementation in libthr. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DAAEC89.1090103>