| duflu | Wow... I've got a client to keep running after a server dies | 07:25 |
|---|---|---|
| duflu | And keep reporting a (higher) framerate :) | 07:25 |
| RAOF | That's awkward. | 07:29 |
| RAOF | Heh. Turns out that rather than making a general interface that's hard to implement making an interface that does just what we need is much easier. :) | 07:30 |
| duflu | Absolutely. Hack from top-to-bottom and then modularize when it becomes necessary. Then you'll end up with the simplest code | 07:32 |
| duflu | That's also fun. DRM reports my refresh rates are 59.95-60Hz. Yet when I measure the actual frame interval it's just below 59.90Hz | 07:48 |
| duflu | I guess it's just a guide... | 07:48 |
| duflu | On the plus side, that's good for my Canon camera, which annoyingly records video at 59.94Hz | 07:49 |
| RAOF | And with that, EOW. | 07:57 |
| === Mirv_ is now known as Mirv | ||
| === davmor2_ is now known as davmor2 | ||
| greyback | alan_g: ping | 11:31 |
| alan_g | greyback: wotcha! | 11:31 |
| greyback | alan_g: heya :) I've question about run_mir. I see of code in that file dealing with signal handling, am I right that Mir intercepts the signal first, then propagates it to the inprocess client? (fatal_signal_cleanup) | 11:32 |
| alan_g | greyback: it has been a while since I looked at that code. IIRC it does some cleanup and then propagates the signal to the previous handler. | 11:34 |
| alan_g | But the cleanup is pretty limited - tell the server to stop and zap the filesystem endpoint (if any) | 11:35 |
| alan_g | alf_: ^^ you're working on changes around this stuff. Do you know? | 11:36 |
| alan_g | greyback: I'm just off to lunch. I can take a look when I get back. | 11:37 |
| === alan_g is now known as alan_g|lunch | ||
| greyback | alan_g|lunch: it's not major, am trying to fix crash bug on unity8 stop, and need to understand exactly what run_mir is doing | 11:47 |
| alf_ | greyback: unless the inprocess client has set new signal handlers, fatal_signal_cleanup gets it first and then propagates to any previous handlers | 12:11 |
| alf_ | greyback: unless the inprocess client has set new signal handlers, *after* run_mir is called, ... | 12:11 |
| greyback | alf_: if I set a signal handler before run_mir is called, does it get run before the one set by run_mir? | 12:13 |
| alf_ | greyback: no, it runs after | 12:14 |
| alf_ | greyback: I assume we are still talking about the auto const intercepted = { SIGQUIT, SIGABRT, SIGFPE, SIGSEGV, SIGBUS }; signals | 12:15 |
| alf_ | greyback: i.e. the fatal signals | 12:15 |
| greyback | alf_: I have 2 issues: (1) when Ctrl+C hit, mir server shuts down, but Qt doesn't realise it. I've worked around it, but it's not great. (2) if Qt (the in process client) quits, I want to stop Mir safely. | 12:19 |
| greyback | http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/view/head:/src/unity-mir/qmirserver.cpp is what we're doing | 12:19 |
| greyback | issue (2) is the one concerning me right now | 12:19 |
| greyback | the bug is if I hit Ctrl+C, the server.stop() on line 63 causes a crash | 12:20 |
| greyback | I suspect it is due to calling stop() on a deleted server, but am not really sure. But this code is getting messier & messier, so want a better approach | 12:21 |
| alf_ | greyback: ok, so ctrl+c (SIGINT) is another matter, it doesn't go through fatal_signal_cleanup | 12:22 |
| alf_ | greyback: To stop the server you can call server_config.the_main_loop()->stop() | 12:23 |
| greyback | alf_: what is DisplayServer::stop for then? | 12:24 |
| alf_ | greyback: or DisplayServer::stop() | 12:24 |
| alf_ | greyback: it's the same | 12:24 |
| greyback | yep | 12:24 |
| greyback | can you see any problem with calling DisplayServer::stop after the client returns? | 12:25 |
| greyback | it works fine if client returns, and mir still running as usual | 12:26 |
| greyback | but it crashes there with SIGINT, presumably Mir is shutting down having received that signal | 12:26 |
| alf_ | greyback: right, so by then the DisplayServer may have been destroyed, so 1. you can call server_config.the_main_loop()->stop() which in the worst case will recreate a main loop and have no effect 2. track server lifecycle with the ServerStatusListener | 12:27 |
| greyback | alf_: ok, will try those, thanks | 12:28 |
| === pete-woods is now known as pete-woods-lunch | ||
| alan_g | greyback: do you still need an answer? (I dropped off over lunch) | 12:58 |
| greyback | alan_g: I'm ok for now, alf helped me, thanks | 12:59 |
| alan_g | :) | 12:59 |
| === tedg` is now known as tedg | ||
| alan_g | alf_: I don't plan to land it in this form (hence it is WIP) but could you review this for me please? https://code.launchpad.net/~alan-griffiths/mir/spike-passing-out-client-fds/+merge/218074 | 13:30 |
| alf_ | alan_g: sure | 13:32 |
| alan_g | dednick: I've cleaned up the client-fd spike a bit since yesterday. Have you had a chance to look at it? Should we look at combining it with the stuff you've been doing? | 13:36 |
| greyback | alf_: hey, using server_config.the_main_loop()->stop() does appear to improve things, but might be exposing a Mir bug, as I now get a crash in hwcVsyncThread | 13:36 |
| greyback | alf_: random crash I should say, sometimes it is fine | 13:36 |
| greyback | also, after a few server crash & restarts, input appears to break completely | 13:38 |
| greyback | on the phone that is | 13:39 |
| dednick | alan_g: thanks haven't had a chance to have much of a look yet. i'll do it this afternoon. | 13:40 |
| alf_ | greyback: can you please try if storing the_main_loop() before run_mir and using the stored variable makes a difference? | 13:40 |
| alan_g | dednick: fine. I'll leave it "parked" until you get back to me. No rush. | 13:41 |
| greyback | alf_: no change | 13:43 |
| alf_ | greyback: ok, we will need to talk to kdub or AlbertA because hwcVsyncThread seems to be in the Android system or drivers | 13:44 |
| alf_ | greyback: It would be helpful if we could figure out the circumstances (esp. timing) under which this happens, e.g., if it happens when the client finishes first and then the server or vice versa etc | 13:47 |
| greyback | alf_: ok. I'm failing to get even a useful stracktrace | 13:47 |
| greyback | alf_: why are we allowing the server to shut down before the client has? | 13:48 |
| alf_ | greyback: who needs stacktraces when there is printf/std::cout ;) | 13:48 |
| greyback | alf_: also being devil for a minute: what do I loose by not using run_mir, but creating, starting & stopping the DisplayServer myself? | 13:49 |
| alf_ | greyback: I am not sure about the details of our interaction with the internal clients will have to look | 13:49 |
| greyback | (that is what I'm doing in the QtCompositor code) | 13:49 |
| alan_g | greyback: you lose convenience | 13:50 |
| greyback | alan_g: I gain the full control over Mir | 13:50 |
| alf_ | greyback: you also lose proper mir shutdown under most circumstances (which is related to convenience, since you can reimplement this yourself of course) | 13:51 |
| alan_g | And with that power comes responsibility. ;) | 13:51 |
| greyback | Mir intercepting and acting upon signals, before anything higher up has a chance to, is hard for the higher up to deal with | 13:51 |
| greyback | I would prefer that Qt is always fully shut down, before Mir shuts down | 13:51 |
| alan_g | greyback: there are serious limits to what can be done in a signal hander. But we can seek a "better way" together... | 13:53 |
| alf_ | greyback: alan_g: perhaps we should extend the ServerStatusListener with a stopping() method, to allow users to act before Mir components actually shut down, but it depends on the particular situation whether this would be helpful or not | 13:54 |
| greyback | alan_g: sure. I need the help :) But this is a problem point for me and Mir, I've always struggled with it to be reliable | 13:54 |
| alf_ | greyback: please join stand-up today if possible and we can discuss a bit there | 13:56 |
| greyback | alf_: ok | 13:56 |
| alan_g | greyback: I missed part of the conversation. But it seems to me that you really want to know Mir intends to shut down - not that a signal has been received. | 13:57 |
| greyback | alan_g: it is the fact that Mir decides to shut down, without the client having any say in the matter, that bothers me | 13:58 |
| greyback | client = the in-process client, the user of libmirserver | 13:59 |
| greyback | it bothers me that a library instigates shutdown on the applicaiton that uses it | 13:59 |
| alan_g | that sounds reasonable. | 13:59 |
| alf_ | greyback: with mir the customer is never right ;) | 13:59 |
| greyback | :D | 14:00 |
| greyback | but the customer is demanding :) | 14:00 |
| alan_g | alf_: in this industry we have "users" not "customers" | 14:00 |
| alan_g | greyback: so, if there were a layer of indirection between run_mir() installing signal handlers and what those handlers do, and you could change and/or wrap the defaults would you be a happy user? | 14:03 |
| alf_ | greyback: alan_g: ... I was about the propose something like that ^^^ | 14:04 |
| greyback | alan_g: alf_: I think that would be good yes. | 14:04 |
| alan_g | All problems in computer science can be solved by another level of indirection | 14:05 |
| alan_g | "All problems in computer science can be solved by another level of indirection" | 14:05 |
| alan_g | ... | 14:05 |
| alan_g | David Wheeler | 14:05 |
| alan_g | alf_: do you want to write & propose something? Or shall I? | 14:08 |
| === dandrader is now known as dandrader|afk | ||
| alf_ | alan_g: greyback: I can do it, unless it's urgently needed today, in which case you have more time until EOD | 14:09 |
| greyback | alf_: my bug is bug 1315251. I wouldn't classify it as a Critical as it's not effecting users, but it's getting in the way of tests. | 14:11 |
| ubot5 | bug 1315251 in unity-mir "unity8 7.86+14.10.20140429.2-0ubuntu1 crashes on recent utopic images" [High,In progress] https://launchpad.net/bugs/1315251 | 14:11 |
| greyback | I'll continue trying to work around it for now | 14:11 |
| alf_ | greyback: ok, we will have an MP by Monday if not today | 14:12 |
| greyback | alf_: thank you | 14:13 |
| alf_ | greyback: still, please join the stand up to ensure we have all the details right | 14:13 |
| greyback | will do | 14:13 |
| === pete-woods-lunch is now known as pete-woods | ||
| === alan_g is now known as alan_g|tea | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g|tea is now known as alan_g | ||
| alf_ | alan_g: trying to understand spike-passing-out-client-fds. So, is the point to allow a client (I guess trusted server?) to request a new connection endpoint and get back an fd for that connection that it will then pass to another client? | 14:49 |
| alan_g | alf_: yes - so the main point is the server -side wiring. The IPC call I introduced will probably morph into a trust related API. | 14:50 |
| anpok | the StubbedServerConfiguration adds two options 'tests-user-real-input' and 'tests-use-real-graphics' .. so that when real-input is not set stubs are used.. | 15:48 |
| anpok | but those parameters are never set. | 15:48 |
| anpok | which is probably because there is yet no method to set parameter in mo::Option | 15:50 |
| alan_g | anpok: you can set them on the command line | 15:52 |
| alan_g | (Or in the environment) | 15:53 |
| anpok | hm the latter seems to be simpler in that cae | 15:58 |
| anpok | *case | 15:58 |
| alan_g | It is the same as any of the other options - the user gets to chose how to set it | 16:04 |
| anpok | alan_g: i mean, thats part of the tests .. mir_test_frameworks | 16:06 |
| alan_g | anpok: I know | 16:06 |
| alan_g | You can put options on the command line or in the environment when using the test framework | 16:07 |
| alan_g | Including the two you mention | 16:07 |
| anpok | i just wonder where the best place for setting those options would be | 16:10 |
| anpok | the StubbedServerConfiguration is a base class for InputTestingServerConfiguration.. that one is used in tests that will only work when real input components are used | 16:12 |
| alan_g | That sounds like a bad idea | 16:13 |
| anpok | yip | 16:13 |
| alan_g | I mean why use a configuration that stubs something you want to use | 16:13 |
| alan_g | ? | 16:13 |
| anpok | it only worked up to know because the InputTestingServerConfiguration overrides methods.. | 16:14 |
| anpok | s/know/now | 16:14 |
| anpok | alan_g: StubbedServerConfiguration, kind of stubs everything with regard to input and graphics.. as far as i can see | 16:15 |
| alan_g | That's the point of it | 16:15 |
| alan_g | The clue is in the name | 16:15 |
| anpok | InputTestingServer "un"-stubs the input part to some degree.. | 16:15 |
| anpok | :) | 16:15 |
| anpok | by overriding again.. | 16:16 |
| * alan_g thinks "bzr blame" might be useful | 16:16 | |
| * alan_g resists the temptation | 16:17 | |
| anpok | :) | 16:17 |
| alan_g | So, don't use the Stubbed config if you don't need it | 16:17 |
| anpok | hm have to check which test also relies on that derived configuration | 16:19 |
| alan_g | anpok: when something doesn't make sense it should be fixed. (Preferably in an MP that just fixes the error.) | 16:20 |
| kgunn_ | anpok: sorry to pester, but you said you couldn't mp b/c of prereq branch had "needs fixing"...racarr's scene observer stuff.... | 16:31 |
| kgunn_ | which branch ? i poked around but couldn't find | 16:31 |
| alan_g | kgunn_: scene observe has landed | 16:39 |
| alan_g | *observer | 16:39 |
| kgunn_ | ack | 16:43 |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader is now known as dandrader|lunch | ||
| === dandrader|lunch is now known as dandrader | ||
| josharenson | I'm trying to use InProcessServer, but it crashes. I think the problem is how I'm setting up the serverConfigration. Is this a valid way to create a server configuration? http://pastebin.ubuntu.com/7381079/ | 18:00 |
| === chihchun is now known as chihchun_afk | ||
| === csslayer_ is now known as csslayer | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!