| === 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 | ||
| === duflu_ is now known as duflu | ||
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|lunch | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g|lunch is now known as alan_g | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| === dandrader is now known as dandrader|lunch | ||
| racarr | Yay InputDispatcher on InputSender is working... | 16:57 |
|---|---|---|
| racarr | though I have to understand this FD limit in glib_main_loop... | 16:57 |
| racarr | and I guess this requires full stack testing (joy joy) | 16:57 |
| racarr | static int const max_write_fds{100}; | 16:59 |
| racarr | (though its 10 in trunk) | 16:59 |
| racarr | in glib_main_loop_sources.cpp | 16:59 |
| racarr | does anyone understand why this is done with a static array? | 16:59 |
| racarr | alf_: ^ ? | 16:59 |
| alf_ | racarr: trying to remember... | 17:03 |
| alf_ | racarr: I think it's so that multiple main loops can handle the signals in a sane way | 17:09 |
| racarr | alf_: Ah...I sorta see...I had just realized that must be the purpose of the | 17:10 |
| racarr | "static std::once_flag" | 17:10 |
| racarr | (which is unfortunately breaking test isolation...) | 17:10 |
| racarr | or I speculate may be :) | 17:11 |
| racarr | Now my problem is just after a few dozen acceptance tests the same one always fails | 17:11 |
| racarr | but passes when run in isolation | 17:11 |
| racarr | with the "Failed to add signal write FD" | 17:11 |
| racarr | exception from glib_main_loop_sources | 17:12 |
| racarr | so the static seems to blame | 17:12 |
| alf_ | racarr: isn't the array cleared when the sources are unregistered in each test? | 17:16 |
| racarr | alf_: Seemingly not...(commenting out the call once and just clearing it on construction does fix the immediate issue) | 17:18 |
| racarr | I dont really understand whats happening yet though | 17:18 |
| racarr | its possible things are not being properly unregistered | 17:18 |
| anpok | alf_: remember? I ran into something similar and fixed it.. | 17:19 |
| anpok | racarr: the idle source may not be executed.. then floats around .. and gets picked up by someone else or worse.. | 17:19 |
| anpok | idle source that cleans up on destruction of the main loop | 17:19 |
| racarr | hmm :/ | 17:21 |
| anpok | https://code.launchpad.net/~mir-team/mir/fix-delayed-sigaction-restore/+merge/249862 | 17:26 |
| anpok | never completed because dispatchable was simpler for my task and because creating a valid test case for the issue was really hard | 17:27 |
| anpok | the test attached caused all sort of issues inside glib | 17:27 |
| alf_ | anpok: so this is a side-effect of the workaround to unref in the idle thread? | 17:28 |
| alf_ | anpok: s/idle thread/idle callback/ | 17:28 |
| anpok | maybe | 17:28 |
| anpok | maybe we have case where the cleanup never happens? | 17:28 |
| anpok | hm or are the fds cleaned up directly, and not together with resetting the sigactions? | 17:29 |
| anpok | hmm but with the fix I only evade the delayed manipulation of sigaction | 17:31 |
| anpok | it does not solve the issue that there is something wrong with the cleanup callback | 17:32 |
| anpok | (or with the library underneath) | 17:32 |
| alf_ | racarr: anpok: I don't have enough info to know if the issue you are seeing is the same anpok saw. In any case, if you have an easily reproducible use case, let me know, and I can take a deeper look. | 17:34 |
| racarr | alf_: Thanks...im sure ill be getting back to youtomorrow :) | 17:34 |
| racarr | I have one more input isolated issue which I am going to | 17:34 |
| racarr | clean up first for sanity | 17:35 |
| anpok | racarr: hmm you could try adding some traces that dump the g_main_context, thread id on main loop construction/destruction/signal cleanup | 17:38 |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader|lunch is now known as dandrader | ||
| === greyback__ is now known as greyback | ||
| === seb128_ is now known as seb128 | ||
| robert_ancell | Where is the XMir branch? | 21:29 |
| mlankhorst | robert_ancell: on fd.org git | 21:30 |
| robert_ancell | mlankhorst, oh hey, still online? :) | 21:30 |
| mlankhorst | http://cgit.freedesktop.org/~mlankhorst/xserver/log/ | 21:31 |
| mlankhorst | you should come online sooner next time though, about to sleep | 21:31 |
| mlankhorst | I'm maintaining it there as a bunch of quilt patches | 21:31 |
| mlankhorst | should probably be moved to a separate branch on top of xorg-server instead | 21:32 |
| robert_ancell | mlankhorst, I assumed you were already off. I was here two hours ago. Is that a good time to talk tomorrow? | 21:32 |
| mlankhorst | are you ever on during mornings? | 21:32 |
| robert_ancell | whose mornings? | 21:32 |
| mlankhorst | < | 21:32 |
| mlankhorst | erll yours | 21:33 |
| robert_ancell | It's my morning now | 21:33 |
| mlankhorst | oh australian time? | 21:33 |
| robert_ancell | New Zealand | 21:33 |
| mlankhorst | ahh | 21:33 |
| robert_ancell | mlankhorst, what works best for you, either two hours earlier than now or in about 9.5 hours (not today though) | 21:35 |
| mlankhorst | about 10 hors from now | 21:35 |
| robert_ancell | OK, I'll try and catch you then in a few days | 21:35 |
| mlankhorst | oke | 21:35 |
| robert_ancell | thanks | 21:36 |
| === c74d is now known as Guest95461 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!