On Wed, 09 Jul 2014 15:43:27 +0900 Nobuhiko Tanibata <[email protected]> wrote:
> 2014-07-07 17:04 に Pekka Paalanen さんは書きました: > > On Tue, 20 May 2014 19:02:56 +0900 > > Nobuhiko Tanibata <[email protected]> wrote: > > > >> 2014-04-25 20:55 に Pekka Paalanen さんは書きました: > >> > On Thu, 20 Mar 2014 16:00:57 +0900 > >> > Nobuhiko Tanibata <[email protected]> wrote: > >> > > >> >> This is launched from hmi-controller by using hmi_client_start and > >> >> create a > >> >> pthread. > >> >> > >> >> The basic flow is as followed, > >> >> 1/ create pthread > >> >> 2/ read configuration from weston.ini. > >> >> 3/ draw png file to surface according to configuration of weston.ini > >> >> 4/ set up UI by using ivi-hmi-controller protocol > >> >> 5/ Enter event loop > >> >> 6/ If a surface receives touch/pointer event, followings are invoked > >> >> according > >> >> to type of event and surface > >> >> 6-1/ If a surface to launch ivi_application receive touch up, it execs > >> >> ivi-application configured in weston.ini. > >> >> 6-2/ If a surface to switch layout mode receive touch up, it sends a > >> >> request, > >> >> ivi_hmi_controller_switch_mode, to hmi-controller. > >> >> 6-3/ If a surface to show workspace having launchers, it sends a > >> >> request, > >> >> ivi_hmi_controller_home, to hmi-controller. > >> >> 6-4/ If touch down events happens in workspace, > >> >> ivi_hmi_controller_workspace_control is sent to slide workspace. > >> >> When control finished, event: > >> >> ivi_hmi_controller_workspace_end_control > >> >> is received. > >> >> > >> >> Signed-off-by: Nobuhiko Tanibata <[email protected]> > >> >> --- > >> >> > >> >> Changes for v2: > >> >> - squash Makefile to this patch > >> >> > >> >> Changes for v3 and v4: > >> >> - nothing. Version number aligned to the first patch > >> >> > >> >> Changes for v5: > >> >> - usleep with roundtrip uses CPU. replace them with > >> >> wl_display_dispatch > >> >> > >> >> ivi-shell/Makefile.am | 2 + > >> >> ivi-shell/hmi-controller-homescreen.c | 1369 > >> >> +++++++++++++++++++++++++++++++++ > >> >> ivi-shell/hmi-controller-homescreen.h | 36 + > >> >> ivi-shell/hmi-controller.c | 3 +- > >> >> 4 files changed, 1409 insertions(+), 1 deletion(-) > >> >> create mode 100644 ivi-shell/hmi-controller-homescreen.c > >> >> create mode 100644 ivi-shell/hmi-controller-homescreen.h > >> > > >> > Would it not be simpler and more robust to make this an independent > >> > program like e.g. clients/desktop-shell.c is, rather than running it in > >> > a thread in the compositor? > >> > > >> > I would certainly prefer it to be. We would avoid threads in the > >> > compositor, and pulling in client side stuff. Now there is a huge risk > >> > you might be calling compositor functions from client code, and a crash > >> > in the client code would bring the whole compositor down. > >> > > >> > If we look at weston-desktop-shell, if it crashes, Weston will respawn > >> > it so fast that a user often does not even notice anything happened. > >> > ;-) > >> > >> I agree. I apply your comments in v5. it is now process. > >> Before, I implemented it as a thread to reduce overhead of process > >> dispatch. > >> I experienced such a overhead before. However at first, I shall follow > >> wayland current sample like desktop-shell, invoke it as process. > >> If ivi vendor want to it as a thread with the same concerning, it can > >> easily do it by itself. > > > > Hmm, would be interesting to hear a bit more about that overhead > > thing. > > > > In your code: > > - it is a thread, so it will be subject to scheduling anyway > > - it still uses a normal Wayland connections (wl_display_connect), > > so it will not skip any of the communication overheads > > > > I'm just curious about what overheads you intended to avoid here. > > Was it library loading at start-up? I can't think of anything else > > right now. > > > > Thanks for comment, pq! > > My concerning was that process dispatch vs thread dispatch. Threads > share their memory space and the dispatch cost might be smaller than > process ones. If I can implement IVI clinet in the same process, it can > reduce dispatch code compare to process dispatching. Hmm, that's a thing I do not know anything about, really. I would not assume there is a difference unless you can show that by measurements. IIRC all threads in Linux (as via pthread library) are kernel threads, and not purely user space things in a single kernel thread per process, which means the kernel does the scheduling and switching. Even if there was a difference, you may still hit the heavier switch if you get a run sequence process-A-thread-1, process-B, process-A-thread-2. And then CPUs today are almost all multi-core, so reasoning about performance gets only harder. Furthermore, as you are still using unix sockets for communication, there will be at least a couple of syscalls per IO-batch anyway, so you are not saving even in the number of syscalls. I would just not speculate or worry about it at all, until there is a tangible case. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
