puzzled: fork +libthr

[Andriy Gapon]

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