[00:07] kgunn, how did it go? [00:11] robert_ancell: thanks again...vt mir demo working [00:11] \o/ [00:11] altho boot was still wonky [00:11] let me check logs [00:14] ok, symptom first...it hung first time in same way, striking keys like mad 2nd time...got it to boot [00:14] so still jumped to vt8 [00:15] but here's the usc log -> https://pastebin.canonical.com/93337/ [00:15] at least it was quite diff this time [00:16] gotta run...getting yelled at [01:16] Ok, what the whatting what? [01:19] duflu: Do you have any experience interposing libc symbols? Particularly: I want bin/unit-tests to wrap open() [01:20] RAOF: Yes, sadly [01:20] Or, even more particularly, I want: [01:20] // If directly opening the DRM device is good enough for X it's good enough for us! [01:20] tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC); [01:20] RAOF: Your new symbols need to be in a new SO [01:20] to go through the mock. [01:21] RAOF: They need to be in a new SO, _and_ LD_PRELOAD'd if they're to override libc [01:22] duflu: Really? Urgh. Looking at the LD_DEBUG=binding output, I see that libudev is binding open() to bin/unit-tests, and my open64 wrapper is getting called (by pthreads, apparently), but libmirserver.so.0 never binds open(). [01:22] Cos normally libc gets in before all your SOs [01:22] RAOF: The SO will use its own, but if you want process-wide wrapping then LD_PRELOAD [01:22] I don't suppose -Wl,-z interpose would make this less painful? [01:23] Hmm, could do [01:23] Not sure [01:23] RAOF: If it's not loaded early, properly, then you'll get some libraries using your version and some using libc's, which is bad [01:24] Heh [01:25] And don't forget to call the real open(), which you will find by dlsym(RTLD_NEXT, "open") [01:25] Yup. [01:25] My wrapper works fine (as demonstrated by open64). [01:28] RAOF: We're lucky it's easy on Linux. When I did it in Windows I had to edit the binary instructions by hand at the start of each function :) [01:28] That sounds like much more fun! [01:28] Which is not so easy on x86 because instructions vary in size. So you have to interpret them first. [01:31] Couldn't you have just padded all your functions with enough noops to make that easier? [01:32] Also: boo. -z interpose is not teh win. [01:47] ... [01:47] !!! [01:51] RAOF: Not my functions. They were Microsoft's :) [01:54] So, my open() wrapper works, as evidenced by LD_PRELOADING it and gdb spitting out the debug spew I've made it emit. [01:54] But, for some reason, tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC); is *not* wrapped. [01:58] Oh. [01:58] That's not fair. [01:59] It's because that line is never called, because of an incorrect ‘!’ further up the function. [03:47] trying to make this work on VMWare still [03:48] mir_demo_client_egltriangle ends on creating a shared ptr for GBMClientBufferFactory and then the server starts executing [03:48] nall: It's not going to work in vmware at the moment; we require dma-buf support from the kms driver, and vmware does not have that support. [03:49] K,gotcha. Thanks [03:50] We do *want* to support vmware, and a fallback non-accelerated case if possible. [03:50] If you want to write code, there's code to be written :) [03:51] Yeah, I'm just trying to figure out where to start. [03:51] I'd love to run Ubuntu natively on my machine but it's a company computer and the only one I've got. [04:06] good morning :9 [04:08] tvoss: Go back to bed you silly man [04:08] And good morning [04:09] duflu, :) all good, today is my early-bird day :) [04:14] tvoss: Were you by any chance profiling Mir with 3 clients/surfaces? (like multiwin?) [04:15] duflu, nope, I started single client [04:15] tvoss: Which one? [04:15] duflu, I think not even an egl one [04:15] tvoss: Multiwin would create 3 surfaces, hence 18% I guess [04:15] duflu, ack [04:16] duflu, the shell/mobile guys were quite happy to hear about cpu optimizations, too [04:16] Though mathematically that does not scale accurately [04:16] duflu, yup :) [04:16] tvoss: Yeah it's quite useful. Re-proposing just now [04:16] duflu, did my comment make sense? [04:17] tvoss: Yes I added refs [04:18] duflu, great [04:18] As usual, spent more time figuring out the gmock errors than making the change [04:19] duflu, for the glclear: How about having an interface ScreenClear that is given to the renderer? We could add a null implementation [04:19] oops, we made it slashdot :) [04:19] tvoss: Yes you got slashdotted [04:19] tvoss: Not sure which class, but the shell should be allowed to override the clear with anything [04:20] tvoss: But then that may become generalized as I figure out a framework for transitions and animations (my main task) [04:21] duflu, ack, I just want to get rid of the glclear in a sane way on a short timescale [04:21] tvoss: https://code.launchpad.net/~thomas-voss/mir/wait-for-vt-to-become-active-before-setting-mode/+merge/171099/comments/381497 [04:22] duflu, not entirely sure, I was thinking about a test case, but hard to come up with one [04:23] tvoss: There is no sane alternative to glClear until the shell renders a background of its own. And even then there's no benefit cos the wallpaper still takes up server CPU time [04:24] Also, I think it was much less than 19% yesterday [04:24] RAOF, where is the debian branch for the mesa build? [04:24] robert_ancell: In the ppa-somethingorother branch of github. [04:25] duflu, fair, but do we really need to clear in the mobile case? the shell will fill the entire display anyways [04:25] robert_ancell, RAOF good morning :) [04:26] tvoss: Good morning. [04:26] tvoss, very early morning to you [04:26] robert_ancell, yup, my early bird day such that I can hug you guys :) [04:26] tvoss: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/+merge/170765 is ready to roll, and should help us understand where sabdfl's laptop is failing [04:27] RAOF, great, let me give it a review [04:27] RAOF, sabdfl was hit by an Input/Output error while setting the mode on the vt, which made me look into the X code for setting up shared vt's -> VT_WAITACTIVE [04:28] RAOF, fails CI on amd64 [04:28] tvoss: Ah, it's just finished then. [04:29] tvoss: The switching animation on mobile still shows black background, briefly, no? [04:30] As the old surface moves away, it no longer fills the screen [04:30] duflu, nope :) that's faked, the shell always paints completely on top and just moves a screenshot of the surface around [04:30] Hence you need a glClear before that [04:30] tvoss: I mean when it's done properly. You still need a clear [04:30] Most frames... but not all [04:30] duflu, +1 :9 [04:31] I am trying to avoid any nasty occlusion calculations like compiz does [04:31] For as long as possible [04:31] But we'll need it for basic fullscreen testing [04:32] tvoss: Boo. That doesn't happen locally, of course. [04:33] RAOF, a quick one at first glance: in class UdevHelper: mind making the ctx pointer private? or class -> struct if you only want value-semantics? [04:33] It's a failure to interpose the open() wrapper, which I *thought* I could get away with but it looks like duflu is annoyingly correct [04:33] ☺ [04:33] robert_ancell, welcome back :) [04:33] session crash :( [04:33] tvoss: Sure. I [04:34] LD_PRELOAD FTW [04:34] tvoss: As the comment mentions, it's going to want to grow into a fully-functional libudev wrapper. [04:34] duflu: On *my* system LD_PRELOAD is unnecessary :( [04:35] Which is going to make testing the fix rather annoying. [04:35] RAOF, fair, but just make the class a struct then :) [04:35] tvoss: Ok. [04:39] hmmm, how can we check if the kernel supports vt's at runtime? apart from randomly opening the actual vt? [04:39] tvoss, I have wondered that myself [04:41] back :) [04:44] * tvoss_ notes https://bugs.launchpad.net/mir/+bug/1194210 [04:44] Launchpad bug 1194210 in Mir "XMir hang during google hangout on intel sandybridge" [Undecided,Incomplete] [04:44] RAOF, but I had those weird hangs w/o xmir, too [04:44] mhall119, ping [04:47] duflu, take it with a grain of salt: but why not leave away the const-qualifier on the transformation and get rid of the mutables? :) [04:47] I see your intention and it's a nice idea, but three members requiring mutable indicates that const might not be appropriate :) [04:49] duflu, apart from that, I'm fine [04:50] tvoss_: I would prefer all read-only "getters" be const, regardless of the mutables required [04:51] If they're not const then that creates problems for const callers [04:51] duflu, fair [04:52] tvoss_: pong === alf is now known as alf_ [04:53] mhall119, for your question what XMir: a vanilla Xorg which knows about Mir, credits to RAOF, here is the diffstat: [04:53] ChangeLog |121618 ++++++++++++++++++++++++++++++++++++ [04:53] configure.ac | 11 [04:53] hw/xfree86/Makefile.am | 9 [04:53] hw/xfree86/common/xf86Bus.c | 2 [04:53] hw/xfree86/common/xf86Config.c | 12 [04:53] hw/xfree86/common/xf86Globals.c | 3 [04:53] hw/xfree86/common/xf86Helper.c | 9 [04:53] hw/xfree86/common/xf86Init.c | 55 [04:54] hw/xfree86/common/xf86Priv.h | 3 [04:54] hw/xfree86/xmir/Makefile.am | 26 [04:54] hw/xfree86/xmir/xmir-output.c | 225 [04:54] hw/xfree86/xmir/xmir-private.h | 83 [04:54] probably should have pastebin'd that [04:55] Ignore the ChangeLog addition, that's spurious :) [04:55] mhall119, probably, it's before third coffee here, don't expect me to be that clever [04:55] RAOF, mind pastebinning the diff-stat, then we can link it on G+, too [04:55] it's almost 1am here, so I won't likely remember this in the morning anyway :) [04:55] mhall119, \o/ [04:56] * tvoss_ tries a sudo apt-get install kubuntu-desktop [04:56] tvoss_: http://paste.ubuntu.com/5797514/ enjoy. [04:56] RAOF, thx [04:58] tvoss_: Oh, any advance on the client-focus-notification thingies? [04:59] RAOF, nope, you just bumped its priority :) [04:59] I would rather like to be able to switch sessions without having all input go to both :) [05:00] RAOF, that's a very sane requirement :) [05:07] RAOF, robert_ancell mind having a final look here and top-approve? https://code.launchpad.net/~vanvugt/mir/fix-1193020 [05:10] tvoss_, duflu, approved [05:10] robert_ancell, thx [05:12] robert_ancell, ta [05:12] * duflu -> lunch [05:13] duflu, enjoy [05:17] robert_ancell: Feel like approving https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140 while I'm on a wait-for-CI-review-fest? [05:17] RAOF, I don't know why he moved the demos to libexec - that doesn't make sense to me [05:18] But if you installed them, you do want to be easily able to run them [05:18] it's not like they're in the main package [05:20] hey RAOF! I think this is perfect timing :) [05:20] didrocks, speak of the devil :) [05:20] didrocks, why demos into libexec? [05:21] robert_ancell: hey! see RAOF's answer! https://code.launchpad.net/~didrocks/mir/packages-fix/+merge/171140/comments/381521 [05:21] duflu, you've got a conflict on https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070 [05:21] didrocks, well, the manpages issue doesn't warrant them moving and if you install the package you expect them to be easily runnable [05:22] robert_ancell: and getting 8 demo_mir_ in your path? :) [05:23] didrocks, yes. The package contains 8 demo applications.. [05:23] robert_ancell: I think as they are seeing as examples, we should do as for other demos, like the Qt ones and having them in a path that's not polluting the $PATH [05:23] seen* [05:23] didrocks, which qt package is this? [05:24] robert_ancell: http://packages.ubuntu.com/raring/i386/qt4-demos/filelist [05:27] didrocks, you can approve if you want [05:28] hmmmm, kubuntu-desktop seems to be in -proposed. didrocks, any idea when that is going to land? [05:28] robert_ancell: thanks! [05:28] tvoss_: kubuntu-desktop? did you look at the migration excuses? [05:28] didrocks, nope [05:31] tvoss_: are you sure about kubuntu-desktop? https://launchpad.net/ubuntu/+source/kubuntu-meta seems that it wasn't uploaded nor blocked for some days [05:31] didrocks, kubuntu-devel's topic says so :) [05:31] robert_ancell: I think kgunn gave to you the bug list we need to check before getting mir into distro? [05:32] tvoss_: well, I trust launchpad for facts, they are maybe talking about kde components, not the package [05:32] didrocks, ah okay [05:32] tvoss_: did you see my question on lttng* btw? [05:32] (yesterday evening) [05:33] didrocks, yep [05:33] Thanks robert_ancell :) [05:34] didrocks, on irc? if so, bear with me, I was doing the session dance [05:35] tvoss_: ok, the question that colin and I had was libmirserverlttng.so and libmirclientlttng.so needs to be in system library path [05:35] tvoss_: as there is no ABI/soname, they normally should be seen as private lib [05:35] so not really sure how lttng picks them, what's the mechanism? [05:35] didrocks, lttng does not pick them, they define and implement lttng probes that feed to the trace if activated [05:36] alf_, ^, mind helping out didrocks? [05:36] didrocks, I think they should have an ABI/soname, though [05:37] tvoss_: the question I guess is how are they activated? Do we tell lttng "please use those libs?" [05:38] didrocks, nope, the implementation in the libs tells lttng on activation: here I am [05:38] didrocks, so it's not a "plugin" to lttng [05:38] hum, I'm a little bit lost on the activation mecanism :) [05:39] didrocks: they are dlopened by Mir internally [05:39] didrocks: right now it's dlopen("limirclientlttng.so"...) [05:39] alf_: ah, so we can install them in a private lib, rather? [05:39] dir* [05:40] alf_: like /usr/lib/x86_64-linux-gnu/mir/tools/ ? [05:40] didrocks: Yes. In that case will I need to use the path when dlopen-ing or will the path be added to LD_LIBRARY_PATH externally? [05:41] alf_: I think on compilation, we set that path in a .h for dlopen-ing, as we can multiarch it [05:41] alf_: mind if we look at that together this morning? [05:41] (like in a couple of hours) [05:42] didrocks: sure, ping me [05:42] thanks! [05:48] alf_, where does the mir log go to, right now? [05:48] tvoss_: You hunted down an “abort in global dtor” bug in the past, didn't you? [05:49] RAOF, yup, how can I help? [05:50] tvoss_: In stdout/stderr but it's not visible on the desktop since we put the VT in graphics mode. You can redirect it or use glog with a file output [05:50] tvoss_: I'm shared-libbing mir-test-doubles (because I need their implementation of open() to be first in the link order), and the unit-tests fail with an abort in testing::internal::GTestLog::~GTestLog [05:51] didrocks, please review https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/171215 [05:51] RAOF, let me have a look. Why are we hit by those fini issues? I still suspect -Bsymbolic-functions, with the linker unloading so's too early [05:53] RAOF, mind running it through ltrace real quick? [05:53] bye all [05:53] tvoss_: Not at all. [05:53] robert_ancell: Night. [05:53] robert_ancell, night [05:53] robert_ancell: have a good night! [05:54] tvoss_: https://code.launchpad.net/~raof/mir/prober-drm-device-probe/ is the branch. [05:55] Wow, ltrace spews a lot of debug output :) [05:55] RAOF, yup, that's how tracked it down last time [05:56] Hm. I take it that “ltrace bin/unit-tests’ shouldn't deadlock? :) [05:57] RAOF, if that is the case, it's almost surely an issue in a pthread_mutex_destroy [05:57] tvoss_: Oh, you mean “[ FATAL ] /home/chris/Canonical/Mir/mir/proper-drm-device-probe/3rd_party/gmock/gtest/include/gtest/internal/gtest-port.h:1486:: pthread_key_delete(key_)failed with error 22”? [05:57] RAOF, something like that :) [05:57] Sorry, should have given that output upfront! [05:58] RAOF, no worries [05:58] RAOF, building your branch right now [05:58] alf_, for the log: I would think something like /var/log/mir/mir.0.log makes sense [05:58] glog does log rotation, too [06:00] alf_, but I would expect the shells pulling in mir to be able to adjust that, so unity-system-compositor setting up the logging [06:01] tvoss_: makes sense [06:02] alf_, let me file a bug on usc [06:10] tvoss_, and again :) https://code.launchpad.net/~vanvugt/mir/fix-1193020/+merge/171070 [06:10] duflu, didrocks do thread-local storage keys cease to exist on so unload? [06:11] tvoss_: No, SOs are not tied to threads [06:11] And they have no automatic destructor [06:12] duflu, hmmm, so in the fini operation of unit-tests, a delete on a pthread key results in an error, although the key was existant before ... [06:13] tvoss_ : You might have another SO/fini bug if it's an old distro [06:13] duflu, it's saucy [06:13] Not likely then [06:14] duflu, nope [06:14] tvoss_: Also pthread_key_delete works by value. It's only an ID. So any error means the key is not a valid one... or you got heap corruption prior [06:15] duflu, right ... just waiting for my debug build to finish [06:15] didrocks, is there a list of changes to low-level userland stuff in saucy? [06:15] tvoss_: yeah, I confirm what duflu says, the libs are loaded globally to a process, weird that you have this pthread issue then [06:15] tvoss_: saucy-changes ML [06:15] it's the only way to track what's in [06:15] I thought Linux was over these kinds of bugs. It's almost certainly an application bug [06:16] still some copyright issues to fix for robert :) https://code.launchpad.net/~robert-ancell/mir/copyright-fix/+merge/171215 [06:16] duflu, right, but I wonder what makes it pop up right now [06:16] this deserves a coffee I guess now :p [06:17] didrocks, exactly [06:17] heh [06:18] duflu, RAOF ah, heap corruptoin :) [06:19] at least gdb says so, valgrind to the rescue then [06:22] okay, there is heap corruption on fini of libmir-test-doubles.so [06:23] arising from a std::string::~string [06:29] alf_: How much would you like a UdevEnumerator RAII wrapper? It's on my TODO list anyway. [06:30] RAOF: I don't consider it urgent enough to block the MP (especially if it's in the queue anyway). [06:30] Cool. [06:32] tvoss_, arising from std::string ? [06:33] buffer overrun? [06:33] duflu, checking [06:33] RAOF, did you just push an update to the prober branch? [06:34] tvoss_: Yeah, but just stylistic changes. [06:34] RAOF, there are some stray characters in there :) [06:35] RGARGHUH. [06:37] Hurray for stray non-printing characters! [06:40] RAOF, oh, and std::static_cast -> static_cast [06:40] Yeah. [06:40] Got that one myself :) [06:46] tvoss_, duflu: Looks like it's double free()ing the string? [06:47] RAOF, yeah, but it's racy and I'm not able to track down the string location [06:47] tvoss_: Is it a static global? Those can easily get double freed [06:47] duflu, already searched for static std::string, nothing test-doubles, next is look through source files and see if we have global strings somewhere [06:48] duflu, although fini should be threadsafe, shouldn't it? [06:48] Bisect! [06:48] Happens when having an indirect link of libmirserver0 [06:48] tvoss_: Well, no I don't think so. Fini doesn't have to be thread safe. It's only every called once, in theory [06:49] tvoss_: Ah linking to client & server libraries? [06:49] It does do that, yes. [06:49] If so then it can happen if there is a global symbol of the same name (as in our input code that's duplicated) [06:49] The first loaded copy gets destructed twice. And the second, never. [06:50] Or not global, but a static class member even [06:50] The solution is to replace it with a static getter function that returns a reference to the real variable (which is static inside the getter function) [06:52] is it me or Mir trunk doesn't build anymore? [06:52] duflu, okay, let me scan through the code [06:52] didrocks, it's obviously you ;) [06:52] tvoss_: See r566 as an example [06:52] tvoss_: saucy, right? [06:53] duflu, although it's a question whether this is faulty linker behavior [06:54] tvoss_, that's a premature and usually naiive argument :) [06:54] didrocks, ack [06:54] duflu, well, my suspicion is that if you remove -Bsymbolic, it wouldn't result in issues [06:55] tvoss_, Yeah you're probably right. But you can modify statics like in r566 so you don't need to remove Bsymbolic [06:55] duflu, I rarely blame the compiler or the linker, but the exposed behavior contradicts the c++ standard. Not saying that is bad necessarily! [06:56] Survey suggests that 3rd_party/gmock/gtest/include/gtest/internal/gtest-death-test-internal.h: static std::string last_death_test_message_; is a possible culprit. [06:56] Well, linkage rules are outside the scope of C* languages, unfortunately [07:00] tvoss_: let's say I'm blaming ccache and I retry without it [07:00] didrocks, branching trunk now :) [07:01] tvoss_: I think it's fine, seems to be ccache + parallel build not playing fine [07:05] tvoss_, thanks for fixing my bug without even being aware :) [07:05] https://bugs.launchpad.net/mir/+bug/1194054 [07:05] Launchpad bug 1194054 in Mir "--vt N option seems to be unreliable/racing" [Medium,Fix committed] [07:06] duflu, \o/ [07:07] didrocks, ack [07:10] tvoss_: duflu: RAOF: alf_: does mirplatformgraphics really belong to the same binary package than libmirserver0? [07:11] (it will follow the same ABI stability I guess?) [07:11] Oh, has loadable backends landed? [07:11] didrocks: They share all their code, and we fully expect parts to move around between them as a driver model materializes [07:11] For the moment it's certainly in libmirserver0 [07:11] RAOF: Landed yes, but it's just the old library made dynamic instead of static [07:12] didrocks: In the future I would expect to have separate packages for the various backends [07:12] RAOF: duflu: alf_: ok, let's keep it that way, then, thanks! [07:12] * didrocks remerges his branch and multiarch that one as well before pushing [07:14] duflu, idea for testing vt's: we request the next free vt and do all of the activation magic and modesetting there [07:17] RAOF, duflu any idea how we can get vts back? [07:17] ECONTEXT. Back from what? [07:18] tvoss_: Ctrl+Alt+F7 to regular X, and then back to your VT (https://bugs.launchpad.net/mir/+bug/1189770) [07:18] ? [07:18] Launchpad bug 1189770 in Mir "[regression] Killing Mir with Ctrl+C often leaves the screen blank and difficult to recover " [High,Triaged] [07:20] tvoss_: I'm not sure any automated tests should be touching real hardware, by default... ? [07:20] duflu, not sure that the trick works. Can we fix that issue somehow? [07:23] tvoss_: Not sure. Maybe our SIGINT handler needs to do cleaner shutdown [07:23] Which is simple [07:23] Haven't looked [07:34] tvoss_: The trick doesn't work if you're using unity-system-compositor :( [07:34] tvoss^ [07:54] okay, found the reason for the double free [07:54] Woo [07:55] but: that still does not solve the issue with the std::string dtor [07:55] RAOF, ^ [07:59] tvoss: How did you find the double-free? [07:59] Also, what is it? :) [07:59] RAOF, let me pastebin the diff [08:02] Hm, or not :) [08:12] RAOF, hold on, compiling :) [08:15] RAOF, http://pastebin.ubuntu.com/5797856/ [08:17] RAOF, there is still some issue reported by valgrind about an invalid free in a string [08:17] RAOF, and busid is a std::string now [08:20] hi [08:20] question :) [08:21] http://unity.ubuntu.com/mir/namespacemir_1_1compositor.html I am looking at the classes here, trying to understand the system and the session compositor... but I am a bit confused [08:22] the system compositor is the Multithreaded Compositor? [08:23] hikiko, nope, why should it? the system compositor is a process on its own [08:24] tvoss_, could you explain me a bit the concept with the 2 compositors or tell me the classes to look at? [08:25] system compositor == the whole mir? [08:25] hikiko, no need to look at classes: every compositor is the whole of mir [08:25] hikiko, the session compositor is just another client to the system compositor [08:26] hikiko, both are independent processes [08:26] every client == session compositor? [08:27] hikiko: Every client of the system compositor is a session compositor. [08:27] hikiko, nope, ordinary apps talk to the session compositor [08:27] hmm I think that my problem then is that I didn't get what exactly the compositor does :S [08:27] in case of mir server I understand [08:27] Ish; we may well have a couple of non-compositor clients of the system compositor (such as a polkit authenticator) [08:27] It combines/renders the win to a surface [08:27] hikiko, it takes buffers and assembles a final output [08:28] yes [08:28] hikiko, in case of the system comp, that is sent to the display [08:28] hikiko, in case of the session comp, that is sent to the system comp. [08:29] so the windows of a client [08:29] are assembled before being sent to the server [08:30] and the server only displays the buffer with all the windows? [08:30] hikiko, no, the windows of clients are surfaces known to the session comp [08:30] so why the session compositor needs the server? [08:31] hikiko, the session compositor is a server in itself. And: it does not know about displays and such and does not have access to the underlying hw [08:31] hikiko, think about user session swithcing: all of these sessions are clients to the system comp [08:32] I think I misunderstood what we call session then :s [08:32] hikiko, ? [08:32] mm [08:33] tvoss_, let's say we have a client (a program that needs to open 2 windows) [08:33] hikiko, what did you consider a session if not a user session? [08:33] hikiko, okay [08:33] a client connection [08:33] but I am wrong obviously :) [08:34] in the example with the 2 windows of a client [08:34] the process is: [08:34] We do have a concept of "session" in the codebase, don't we. [08:34] RAOF, yup, every application is a session [08:34] then I was right? [08:34] hikiko, nope [08:34] tvoss_: So, it's not entirely strange to be confused about the overloaded “session” nomenclature :) [08:35] RAOF, it is overloaded for a good reason: all sessions are connections in the end [08:35]