| === duflu_ is now known as duflu | ||
| alf_ | fginther: no worries, I hope you feel better | 07:11 |
|---|---|---|
| dandrader | alf_, ping | 08:47 |
| alf_ | dandrader: hi | 08:47 |
| dandrader | alf_, hi. I manually built&"make install" mir, but when running an application now I get "libmirplatformgraphics.so: cannot open shared object file: No such file or directory". I guess it's because of "debian: Provide platform packages managed with dpkg alternatives." | 08:49 |
| dandrader | alf_, so, what's the simplest/correct way of handling this? | 08:49 |
| dandrader | ie., what script or command should a manually run after "make install"? | 08:50 |
| alf_ | dandrader: simplest workaround is: cd to install libdir (e.g. /usr/lib/{arch}) and ln -s mir/platformgraphics/mesa/libmirplatformgraphics.so | 08:56 |
| alf_ | dandrader: and ln -s mir/clientplatform/mesa/libmirclientplatform.s | 08:56 |
| alf_ | dandrader: where s/mesa/android/ if you want the android version | 08:57 |
| dandrader | alf_, I wonder if "make install" should already do such things... | 08:58 |
| alf_ | dandrader: I should fix it so that things work after a make install | 08:58 |
| alf_ | dandrader: yes | 08:58 |
| dandrader | alf_, should I file a bug to track this? | 08:59 |
| alf_ | dandrader: the problem is that this conflicts with how debian alternatives work, but I guess we can just not install the links in the debian packages | 08:59 |
| alf_ | dandrader: @bug, sure | 09:00 |
| dandrader | I'm not really familiar with debian alternatives | 09:00 |
| alf_ | dandrader: a potential issue is if you mix "make install" and using packages, then the debian alternatives won't really work because make install will place direct soft links to the .so | 09:03 |
| alf_ | dandrader: but I guess, whoever plays with fire will get burned :) | 09:04 |
| alf_ | duflu: alan_g: anpok: https://bugs.launchpad.net/mir/+bug/1194384 , is our goal to provide a way to serialize the events for apps that don't need full multithreading flexibility? I don't remember if discussions about this (if any), led to a conclusion. | 09:27 |
| ubot5 | Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Critical,Triaged] | 09:27 |
| duflu | alf_: The goal is to ensure all callbacks occur in one thread. The same thread as main() | 09:28 |
| alan_g | alf_: IIRC in London RAOF had some ideas about this. I know duflu had a prototype for putting everything onto a client thread | 09:29 |
| duflu | I did a proof of concept which works. But it adds a little latency (additional context switch) | 09:29 |
| duflu | That actually increases motion event throughput a lot, but it feels slightly laggy | 09:29 |
| duflu | Like most toolkits, you provide an API call from the client into the client library. And that's then a jumping off point to call the callbacks. People often use a "Mainloop" object for that | 09:31 |
| duflu | I think I did it similarly, but more generally. In a way where we could change the mechanics underneath over time | 09:31 |
| alf_ | duflu: alan_g: Do we still need to allow for multiple threads (i.e., the current situation)? I am not sure what our requirements from the toolkit side are. | 09:33 |
| duflu | alf_: I'm not sure what you mean | 09:33 |
| duflu | alf_: Oh. I see. Supporting single plus multiple would be a requirement. But once you have the former, the latter is simple | 09:34 |
| === dandrader is now known as dandrader|afk | ||
| alf_ | duflu: you mean dispatching to multiple threads from the main thread? | 09:34 |
| alf_ | duflu: but in an application/toolkit-controlled fashion | 09:35 |
| duflu | alf_: Regardless the public API should not suggest the existence of threads or ever call back the client in some different thread. You can hide threads underneath still | 09:35 |
| duflu | alf_: Shall I revive the prototype? It was designed to provide an interface to fix on so we can improve the underlying efficiency later | 09:36 |
| duflu | I think the greatest benefit of the prototype was that I designed it so no existing clients needed modification. It's an optional add-on to enforce single threaded-ness | 09:40 |
| alf_ | duflu: I am trying to figure out what our goals our... so, as I see it, ideally we would like to get rid of the various set_callback functions and callback arguments, and just dispatch everything through the mainloop/event_queue? | 09:41 |
| duflu | alf_: If starting from scratch then yes. But right now we'd like to maintain transparent compatibility with existing clients too | 09:42 |
| * duflu copies and pastes | 09:43 | |
| duflu | alf_: The goal is to ensure all callbacks occur in one thread. The same thread as main() | 09:43 |
| alf_ | duflu: From what I see the goal is for the callbacks to occur in one thread, any thread the app/toolkit wants? | 09:44 |
| duflu | alf_: Yes, that too. But that can be accomodated with the more stringent goal of a single-threaded client should only ever see callbacks in its main() thread | 09:45 |
| duflu | Of course, the client can control which thread that is | 09:45 |
| duflu | alf_: So long as the basic requirement is met and the API is pretty, I'm happy to ignore my prototype work | 09:46 |
| alf_ | alan_g: duflu: anpok: ok, so the plan is to think a bit more about it, come up with some ideas and a rough plan, and send an email to mir-devel for further discussion | 09:57 |
| alan_g | alf_: ok | 09:57 |
| === psivaa-afk is now known as psivaa | ||
| duflu | alf_: Cleaned up: https://code.launchpad.net/~vanvugt/mir/event-queue/+merge/208563 | 10:12 |
| alf_ | duflu: great, thanks | 10:12 |
| duflu | I never got as far as writing tests. Still was in the process of redesigning constantly to make everything feel nicer for clients | 10:12 |
| duflu | I designed it from the demo clients, outward :) | 10:13 |
| === dandrader|afk is now known as dandrader | ||
| anpok | owe possible way would be to have no threads created at all but provide an interface to get all client file descriptors to do the wait in a different main loop library (like boost::asio :)) and let the mir client read events when necessary from the fds.. | 10:57 |
| anpok | but there are some odd cases like blocking calls | 10:57 |
| anpok | input requires one fd per surface? | 10:58 |
| anpok | still mir client has to be entirely thread safe | 10:58 |
| anpok | as in allow processing events from multiple threads | 10:59 |
| === shuduo_ is now known as shuduo | ||
| greyback_ | Any Mir person able to help this guy: https://lists.launchpad.net/ubuntu-phone/msg06616.html | 12:00 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g is now known as alan_g|lunch | ||
| === dandrader|afk is now known as dandrader | ||
| === pete-woods is now known as pete-woods-lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| anpok | greyback_: I can confirm that this happens.. not sure how to solve it | 13:47 |
| greyback_ | anpok: ok, thanks for looking. Would be nice if someone could help, what he's trying sounds reasonable | 13:49 |
| alan_g | greyback_: it sounds reasonable, but I don't think anyone's looked into supporting that stack. (I know that RAOF had to make mesa changes when he got XMir working on the desktop.) | 13:51 |
| === dandrader is now known as dandrader|afk | ||
| kgunn | mterry: i'm curious...with nested mir & u-s-c...would it make sense for u-s-c to "remove" the tmp socket if it hits this error | 15:34 |
| kgunn | https://bugs.launchpad.net/mir/+bug/1285084 | 15:34 |
| ubot5 | Ubuntu bug 1285084 in Mir "Exceptions are raised in a compositing thread and not handled" [Undecided,New] | 15:34 |
| kgunn | u-s-c is root right ? | 15:35 |
| * mterry looks | 15:35 | |
| mterry | kgunn, yes | 15:35 |
| === pete-woods-lunch is now known as pete-woods | ||
| kgunn | mterry: i would think that if there's already an old socket there...its a mistake(e.g. its old) if u-s-c is just starting up | 15:36 |
| mterry | kgunn, you mean it would make sense for USC to remove /tmp/mir_socket after it crashes? | 15:36 |
| kgunn | mterry: sure | 15:36 |
| kgunn | mterry: or even if it finds one on startup right ? | 15:36 |
| === alan_g is now known as alan_g|tea | ||
| kgunn | trying to think of why it would ever encounter an already existing mir socket ? | 15:37 |
| mterry | kgunn, in general I would think that's true (that Mir would automatically remove old sockets when it starts). But mir-team I thought was of the other opinion | 15:37 |
| mterry | Even for user sessions and such | 15:37 |
| kgunn | alan_g|tea: alf_ ^ | 15:37 |
| kgunn | mterry: maybe not mir itself...but u-s-c would have "knowlege" enough to say "hey, i'm the king daddy mir server starter...if i find an old socket, i should delete it" | 15:39 |
| kgunn | ? | 15:39 |
| mterry | kgunn, sure, but user Mir sessions are king daddy Mir servers in the user session. And are explicitly given a Mir socket path to use. Seems like they should be able to expect to own it | 15:40 |
| mterry | Maybe only assume Mir owns it if we are given the path (which is always the case right now) | 15:40 |
| alf_ | kgunn: iirc, the upstart scripts remove stale sockets before starting usc or unity8 (at least that was the case at some point) | 15:40 |
| mterry | alf_, USC isn't managed by upstart right now | 15:40 |
| mterry | I guess lightdm could do it manually | 15:40 |
| mterry | But would be easier if Mir just did this itself | 15:41 |
| alf_ | kgunn: mterry: mir does it best to remove sockets when it fails, but can't catch all kind of crashes | 15:41 |
| mterry | alf_, I get that. But I'm talking about on startup, removing the socket | 15:42 |
| kgunn | alf_: mterry ...we do need to come up with something CI/release team chasing us....as its wreaking havoc on them | 15:42 |
| mterry | oh really | 15:42 |
| alf_ | mterry: kgunn: the reason it doesn't do this on startup is that this would allow "stealing" a socket from another mir instance | 15:43 |
| mterry | alf_, who are we stopping from doing that? couldn't the user just rm the file themselves? | 15:44 |
| kgunn | yeah...but aren't sockets tied only to that user (in terms of permissions) | 15:44 |
| alf_ | mterry: kgunn: it's not about security, it's about expected behavior, e.g., running two mir instance in a row shouldn't cause the first one to fail because the second steals the socket | 15:45 |
| mterry | alf_, but in both cases you are explicitly specifying the mir socket path. I think behavior in that case is up for debate | 15:46 |
| mterry | Either the first or the second fails | 15:46 |
| kgunn | right | 15:46 |
| * kgunn agrees with mterry | 15:46 | |
| kgunn | which is exactly where we are at | 15:46 |
| kgunn | second one fails cause no one deleted the prior socket | 15:47 |
| kgunn | and from a "theoretical" use case perspective...i don't disagree with alf_ but practically, in our configs when do we have a 2nd usc mir showing up? | 15:48 |
| alf_ | kgunn: mterry: I disagree, expected behavior is for the second to report an error, not for the first one to fail because we pull the socket beneath its feet. And actually the second probably won't fail at all, it's just that the socket will have no representation on the filesystem. | 15:48 |
| kgunn | alf_: so it should create a seperate specific socket? | 15:49 |
| alf_ | kgunn: mterry: since everything is done through upstart, the logic to handle the stale socket was put there | 15:49 |
| mterry | alf_, but with upstart, you get the behavior that starting a second instance kills the first anyway | 15:49 |
| mterry | So I'm not sure why that is an unexpected outcome | 15:49 |
| === alan_g|tea is now known as alan_g | ||
| mterry | I mean, I guess you have to be a bit more explicit. | 15:49 |
| mterry | Saying restart instead of start | 15:50 |
| kgunn | mterry: e.g. upstart is just gonna delete that socket any way ? | 15:50 |
| mterry | kgunn, I thought our upstart script did that? | 15:50 |
| * mterry checks | 15:50 | |
| alf_ | kgunn: mterry: correction: "And actually the second probably won't fail at all" => And actually the *first* probably won't fail at all | 15:50 |
| alan_g | I thought the intention for USC was not to put an endpoint on the filesystem | 15:50 |
| alan_g | In which case all this is moot | 15:50 |
| mterry | kgunn, nope, it doesn't | 15:50 |
| mterry | my bad | 15:50 |
| mterry | alan_g, that was a goal | 15:51 |
| alan_g | What's stopping it? | 15:51 |
| alf_ | alan_g: even if we forget USC, the debate stands about the unity8 socket | 15:51 |
| * alan_g doesn't like software that silently "fixes" things | 15:52 | |
| kgunn | so as a recap, we really have no mechanism to prevent stale/orphaned sockets...not in upstart, not in usc, not in mir | 15:52 |
| mterry | alan_g, no one ever completed the branches robert_ancell started to use the socket-less communication work between lightdm/USC/Mir | 15:52 |
| mterry | alan_g, I actually thought you had that on your TODO somewhere | 15:53 |
| mterry | kgunn, I think autopilot cleans them up :) | 15:53 |
| kgunn | mterry: lol...well obviously not | 15:53 |
| * alan_g can see it (far down the list) | 15:53 | |
| mterry | :) | 15:53 |
| alan_g | mterry: I had a look, but the lightdm code wasn't clear to me | 15:54 |
| kgunn | mterry: AP meaning...some poor bastard manually adb shell's in and rm's it | 15:54 |
| mterry | alan_g, in future, I might be able to help decipher it | 15:54 |
| alan_g | Anyway, unless something SIGKILLS mir it should clean up the socket | 15:55 |
| mterry | kgunn, in unity8's launch_unity() AP method, it cleans its session socket | 15:55 |
| kgunn | alan_g: sorry...no being a smart alec "it" == ? | 15:55 |
| mterry | kgunn, but that's only for the session and only for unity8 tests | 15:55 |
| mterry | kgunn, I think 'it' == mir | 15:56 |
| kgunn | mterry: right, i'm guessing this is all because nested/usc got turned on | 15:56 |
| alan_g | kgunn: mir cleans up the socket on most signals and on normal exit | 15:56 |
| kgunn | ta | 15:56 |
| alan_g | Mir can't do it on SIGKILL | 15:56 |
| kgunn | right, which is exactly how unity8 AP works i think | 15:57 |
| kgunn | as mir is part of the unity8 process | 15:57 |
| * alan_g what's wrong with SIGTERM? | 15:57 | |
| alan_g | *wonders | 15:58 |
| mterry | kgunn, so AP is exercising the system much more than usual, and with less stable code. Maybe it should just clean all the sockets all the time in case it hits crashes | 16:01 |
| mterry | I guess it would have to tell if it's still running. And USC doesn't cleanly restart itself if it crashes... | 16:02 |
| mterry | Just restart system after every test ;) | 16:03 |
| kgunn | om26er: ping | 16:27 |
| om26er | kgunn, hi | 16:27 |
| kgunn | om26er: hiya | 16:27 |
| kgunn | so you can see we've had a lengthy discussion above about | 16:27 |
| kgunn | https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1285215 | 16:27 |
| ubot5 | Ubuntu bug 1285215 in mir (Ubuntu) "Unity fails to start sometimes in CI resulting in screen unlock failure [what(): bind: Address already in use]" [Medium,Triaged] | 16:27 |
| kgunn | curious...do you know how the AP test | 16:27 |
| kgunn | framework works ? | 16:28 |
| kgunn | e.g. does it SIGKILL unity8 ? | 16:28 |
| kgunn | seems mir should clean up the socket if "treated politely"...potentially with SIGTERM | 16:28 |
| om26er | kgunn, this is the script thats run http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/utils/target/unlock_screen.py | 16:28 |
| om26er | we set an upstart override to load the testability driver, stop unity8, turn on the screen and start it again | 16:29 |
| om26er | kgunn, we use initctl stop unity8 | 16:29 |
| om26er | dr appointment, back in 30 | 16:33 |
| kgunn | om26er: ack | 16:33 |
| kgunn | alan_g: mterry ....so guessing this implies, it is just post-crash case... | 16:34 |
| kgunn | so mterry guessing you're suggestion might need to be the one...force clean from AP setup | 16:34 |
| mterry | kgunn, but also if we're talking USC (are we?), might need to restart lightdm | 16:36 |
| kgunn | yes, i think we are | 16:38 |
| kgunn | well...judging from some chat in ubuntu-ci-eng that they needed to be root to delete the stale socket | 16:39 |
| mterry | kgunn, was the stale socket in /tmp/mir_socket or /run/user/.../mir_socket ? | 16:40 |
| mterry | kgunn, because that bug title at least indicates just a user sesion issue | 16:40 |
| === d-snp_ is now known as d-snp | ||
| mterry | Regardless, a problem with USC can be fixed by restarting lightdm (once my fix for bug 1285234 lands) | 16:41 |
| ubot5 | bug 1285234 in lightdm (Ubuntu) "lightdm on touch leaves a unity-system-compositor process around" [Undecided,Incomplete] https://launchpad.net/bugs/1285234 | 16:41 |
| kgunn | mterry: btw, you might want to review this one... | 16:48 |
| kgunn | https://code.launchpad.net/~albaguirre/unity-system-compositor/add-power-off-delay-option | 16:48 |
| kgunn | :) | 16:48 |
| kgunn | i know it will bring you joy | 16:49 |
| mterry | kgunn, interesting. I thought we just needed to clear some buffers in Mir for this | 16:50 |
| kgunn | mterry: well...it was actually to do with the powerd chain of events | 16:50 |
| kgunn | unity8 getting notified after usc | 16:50 |
| mterry | This seems hacky, like what if system load is high or some such | 16:50 |
| kgunn | right... | 16:51 |
| kgunn | mterry: so we're not claiming this to be the final solution | 16:51 |
| mterry | Yar | 16:51 |
| kgunn | i've asked AlbertA to dive in and untangle the whole powerd thing | 16:51 |
| * mterry tests this branch | 16:52 | |
| AlbertA | mterry: yeah it's a kludge for now | 16:52 |
| mterry | Will need a corresponding ubuntu-touch-session change to pass args | 16:52 |
| AlbertA | mterry: I don't think flushing buffers in mir is enough either | 16:52 |
| AlbertA | mterrty: as we should allow shutdown animations to occur | 16:52 |
| AlbertA | mterry: the option can be configured with unity-system-compositor.conf as well | 16:53 |
| mterry | AlbertA, someone mentioned turn-on delays/animations too, since the greeter needs a moment to get the right time | 16:54 |
| AlbertA | mterry: umm that would be a little bit more involved | 16:57 |
| === alan_g is now known as alan_g|EOD | ||
| kgunn | mterry: so i been thinking...why couldn't mir check to see if there's another mir process running, if not...he deletes the socket | 20:03 |
| kgunn | am i missing something | 20:03 |
| kgunn | ? | 20:03 |
| kgunn | ....sorry, picking up from our conversation with alf_earlier | 20:03 |
| mterry | kgunn, well, in theory many Mirs can be running at the same time. As long as they don't have the same socket specified | 20:03 |
| kgunn | mterry: right, but in our config...that's never gonna happen right ? | 20:05 |
| kgunn | we're gonna have one root, and one session | 20:05 |
| kgunn | ...again, am i being stupid ? | 20:05 |
| mterry | kgunn, I guess? But that's going a step further than we need. We can just say "delete the socket you're configured for before opening it for yourself" which is what I was suggesting earlier. No reason to query for other Mirs | 20:06 |
| mterry | Heh, didn't mean "I guess you are being stupid" :) | 20:07 |
| kgunn | mterry: :) | 20:09 |
| kgunn | mterry: so i'm lost...isn't ' just say "delete the socket you're configured for before opening it for yourself" ' what alf_ argued against ? | 20:10 |
| mterry | kgunn, yes | 20:10 |
| kgunn | hmmm | 20:10 |
| mterry | kgunn, but that's also what you are suggesting | 20:10 |
| mterry | kgunn, oh | 20:10 |
| kgunn | yes i know...guess i'm saying not convinced | 20:11 |
| mterry | kgunn, maybe not. I see what you are saying now | 20:11 |
| mterry | kgunn, you want to gracefully exit if there is another Mir | 20:11 |
| kgunn | hey, i just joined a hangout i gotta pay attn :) | 20:11 |
| kgunn | back in a moment | 20:11 |
| mterry | kgunn, we could just call "fuser $MIR_SOCKET" and if no one else is using it, delete it | 20:11 |
| kgunn | ooo... mterry i'd never heard of fuser, just learned from google...i likie | 20:18 |
| kgunn | alf_: ^ | 20:18 |
| Saviq | mterry, btw, fuser is not installed on the phone :/ | 20:53 |
| mterry | Saviq, hrm. I suppose it could be installed or the system call it does could be called directly (unless it does a bunch of direct ext calls... ::shudder::) | 20:56 |
| === seb128_ is now known as seb128 | ||
| === GridCube_ is now known as GridCube | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!