[09:15] <duflu_> Ugg. Another problem that apparently can't be solved without measuring time intervals
[09:16] <duflu_> I hate those
[10:07] <duflu> To the cookery
[10:07] <duflu> Verb or noun, either way
[15:25]  * 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
[15:28] <kdub> which test?
[15:28] <kdub> alan_g,
[15:41] <alan_g> kdub: MirSurfaceVisibilityEvent
[15:44]  * kdub doesnt know much about that one
[15:49] <alan_g> kdub: knows even less about my changes to it
[16:59] <alan_g> alf: 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 MultiThreadedCompositor::start() so that it only returns once the compositing threads have completed initialization?
[17:03] <alf> alan_g: It should be safe
[17:04] <alf> alan_g: I guess it depends on what point you consider the compositing threads to have completed initialization
[17:05] <alan_g> after the call to report->added_display()
[17:10] <alf> alan_g: 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.
[17:11]  * alan_g is trying it
[17:14] <alf> alan_g: However, it is an added risk, since we can't control what other implementations of the involved will do.
[17:14] <alf> alan_g: Plus the point is arbitrary, e.g., why not after scene->register_compositor ?
[17:15] <alf> alan_g: It depends on what guarantee we want to provide for Compositor::start()
[17:16] <alan_g> alf: actually that's probably better
[17:28]  * alan_g breaks mir_unit_tests.MultiThreadedCompositor.*
[17:46]  * alan_g hates MultiThreadedCompositor anyway
[17:46] <alan_g> The test that is
[17:49] <kdub> yeah,it runs too long
[17:51] <alan_g> And that is because it relies on real time rather than synchronization
[17:51] <alan_g> Hence it is broken
[17:52] <alan_g> I could "fix" my race condition like that too.
[17:54]  * alan_g is no longer sure he broke anything with his changes
[18:16] <dandrader> are there -dbg packages for mir?
[18:44]  * dandrader reads https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
[20:16] <racarr> dandrader: Hi no rush (e.g. next week is fine)
[20:16] <racarr> but would appreciate your feedback on https://code.launchpad.net/~mir-team/mir/introduce-mir-event-2.0/+merge/242443
[20:16] <racarr> dandrader: I don't know if you've seen notes doc outlining the direction too?
[20:16] <dandrader> racarr, no, I haven't
[20:17] <dandrader> racarr, will take a look at this MP next week. nearing my EOD now
[20:17] <racarr> dandrader: :) Happy weekend
[20:17] <racarr> I will CC you the email with the notes so you have it
[20:17] <dandrader> racarr, thanks :)
[20:17] <dandrader> same to you