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