[PATCH weston-ivi-shell v5 6/9] A reference implementation of UI client how to use ivi-hmi-controller.

[Pekka Paalanen]

On Wed, 09 Jul 2014 15:43:27 +0900
Nobuhiko Tanibata <nobuhiko_tanibata at xddp.denso.co.jp> wrote:

> 2014-07-07 17:04 に Pekka Paalanen さんは書きました:
> > On Tue, 20 May 2014 19:02:56 +0900
> > Nobuhiko Tanibata <nobuhiko_tanibata at xddp.denso.co.jp> wrote:
> > 
> >> 2014-04-25 20:55 に Pekka Paalanen さんは書きました:
> >> > On Thu, 20 Mar 2014 16:00:57 +0900
> >> > Nobuhiko Tanibata <NOBUHIKO_TANIBATA at xddp.denso.co.jp> 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 <NOBUHIKO_TANIBATA at xddp.denso.co.jp>
> >> >> ---
> >> >>
> >> >> 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