User1: Ugg. Another problem that apparently can't be solved without measuring time intervals
User1: I hate those
User2: To the cookery
User2: Verb or noun, either way
 * alan_g wonders why running all the tests at once causes a consistent failure in the one he's hacking. But repeated solo runs don't cause trouble
User3: which test?
User3: alan_g,
User4: User3 MirSurfaceVisibilityEvent
 * kdub doesnt know much about that one
User4: User3 knows even less about my changes to it
User4: User5 I'm trying to track down a race condition. What I need is a sync point where the DisplayBufferCompositor objects have been created - is it safe to add a barrier in MultiThreadedCompositorbd6c:f4c4:4f6:c742:59d8:35db:68f6:4d5fstart() so that it only returns once the compositing threads have completed initialization?
User5: User4 It should be safe
User5: User4 I guess it depends on what point you consider the compositing threads to have completed initialization
User4: after the call to report->added_display()
User5: User4 well, assuming that the code in the compositing thread until that point doesn't interact with the compositor in ways that can cause a deadlock, which is a perfectly reasonable expectation, it should be OK.
 * alan_g is trying it
User5: User4 However, it is an added risk, since we can't control what other implementations of the involved will do.
User5: User4 Plus the point is arbitrary, e.g., why not after scene->register_compositor ?
User5: User4 It depends on what guarantee we want to provide for Compositorbd6c:f4c4:4f6:c742:59d8:35db:68f6:4d5fstart()
User4: User5 actually that's probably better
 * alan_g breaks mir_unit_tests.MultiThreadedCompositor.*
 * alan_g hates MultiThreadedCompositor anyway
User4: The test that is
User3: yeah,it runs too long
User4: And that is because it relies on real time rather than synchronization
User4: Hence it is broken
User4: I could "fix" my race condition like that too.
 * alan_g is no longer sure he broke anything with his changes
User6: are there -dbg packages for mir?
 * dandrader reads https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
User7: User6 Hi no rush (e.g. next week is fine)
User7: but would appreciate your feedback on https://code.launchpad.net/~mir-team/mir/introduce-mir-event-2.0/+merge/242443
User7: User6 I don't know if you've seen notes doc outlining the direction too?
User6: racarr, no, I haven't
User6: racarr, will take a look at this MP next week. nearing my EOD now
User7: User6 :) Happy weekend
User7: I will CC you the email with the notes so you have it
User6: racarr, thanks :)
User6: same to you
ubuntu-mir
Ubuntu IRC