| === 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 | ||
| duflu_ | Ugg. Another problem that apparently can't be solved without measuring time intervals | 09:15 |
|---|---|---|
| duflu_ | I hate those | 09:16 |
| === duflu_ is now known as duflu | ||
| duflu | To the cookery | 10:07 |
| duflu | Verb or noun, either way | 10:07 |
| === 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 | ||
| * 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:25 | |
| kdub | which test? | 15:28 |
| kdub | alan_g, | 15:28 |
| alan_g | kdub: MirSurfaceVisibilityEvent | 15:41 |
| * kdub doesnt know much about that one | 15:44 | |
| alan_g | kdub: knows even less about my changes to it | 15:49 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|lunch | ||
| 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? | 16:59 |
| alf | alan_g: It should be safe | 17:03 |
| alf | alan_g: I guess it depends on what point you consider the compositing threads to have completed initialization | 17:04 |
| alan_g | after the call to report->added_display() | 17:05 |
| 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:10 |
| * alan_g is trying it | 17:11 | |
| 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:14 |
| alf | alan_g: It depends on what guarantee we want to provide for Compositor::start() | 17:15 |
| alan_g | alf: actually that's probably better | 17:16 |
| * alan_g breaks mir_unit_tests.MultiThreadedCompositor.* | 17:28 | |
| * alan_g hates MultiThreadedCompositor anyway | 17:46 | |
| alan_g | The test that is | 17:46 |
| === dandrader|lunch is now known as dandrader | ||
| kdub | yeah,it runs too long | 17:49 |
| alan_g | And that is because it relies on real time rather than synchronization | 17:51 |
| alan_g | Hence it is broken | 17:51 |
| alan_g | I could "fix" my race condition like that too. | 17:52 |
| * alan_g is no longer sure he broke anything with his changes | 17:54 | |
| === alan_g is now known as alan_g|EOW | ||
| dandrader | are there -dbg packages for mir? | 18:16 |
| * dandrader reads https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages | 18:44 | |
| 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:16 |
| 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 | 20:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!