<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters." href="https://bugs.freedesktop.org/show_bug.cgi?id=98172#c29">Comment # 29</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Concurrent call to glClientWaitSync results in segfault in one of the waiters." href="https://bugs.freedesktop.org/show_bug.cgi?id=98172">bug 98172</a> from <a class="email" href="mailto:shinji.suzuki@gmail.com" title="Suzuki, Shinji <shinji.suzuki@gmail.com>"> Suzuki, Shinji</a> <pre>Sorry. I looked at only your latest comment when I replied previously because I read it in email. You are absolutely right. fence_finish() MUST run concurrently even if they target same sync-object because, as you say, timeout setting in waits may be different. I was thinking only in terms of infinite waits. I'll reapply your patch and continue watching how my app behaves. Thank you for noticing this before I post my buggy patch to the mailing list. BTW, st_check_sync and st_client_wait_sync() seem identical except for the existence of flags and timeout. Should they be merged? (In reply to Michel Dänzer from <a href="show_bug.cgi?id=98172#c26">comment #26</a>) > (In reply to Marek Olšák from <a href="show_bug.cgi?id=98172#c24">comment #24</a>) > > Hm. Probably none. > > Actually, I think there are: E.g. consider one thread calling > glClientWaitSync with a non-0 timeout, blocking for some time with the mutex > locked. If another thread calls glClientWaitSync with a 0 timeout (or > whichever API call ends up in st_check_sync) during that time, it'll block > until the first thread unlocks the mutex.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>