pthread_cond_{timedwait,wait} are allowed to spuriously wake up as if
they were signaled. To prevent this being interpreted as a "real"
signaling of the event (ThreadWrapper for instance depends on it being
an actual signal) we need to check whether the event was actually
signalled or not.
BUG=4413
R=andresp@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49369004
Cr-Commit-Position: refs/heads/master@{#8752}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8752 4adac7df-926f-26a2-2b94-8c16560cd09d
Removes ThreadPosix::InitParams and a corresponding wait for an event.
This unblocks ThreadPosix::Start which had to wait for thread scheduling
for an event to trigger on the spawned thread, giving faster Start()
calls.
BUG=4413
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43699004
Cr-Commit-Position: refs/heads/master@{#8709}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8709 4adac7df-926f-26a2-2b94-8c16560cd09d
It's OK that state is kDown when a thread is woken after being
signalled; another tread might also have woken and already set the state
to kDown.
Even if this waking and aquiring lock has been delayed until other
threads have set state to kDown and then subsequently to kUp again with
a new Set() call, it's OK to just set kDown and return since this thread
is returning kEventSignaled after the (new) Set() has ben called.
R=pbos@webrtc.orgTBR=tommi@webrtc.org
BUG=
Review URL: https://webrtc-codereview.appspot.com/36109004
Cr-Commit-Position: refs/heads/master@{#8334}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8334 4adac7df-926f-26a2-2b94-8c16560cd09d
