Bug 3981 - (int-146739) liblocation possibly relies on application using the default GMainContext
(int-146739)
: liblocation possibly relies on application using the default GMainContext
Status: RESOLVED WORKSFORME
Product: Location
General
: 5.0/(1.2009.41-10)
: All Linux
: Low normal with 2 votes (vote)
: ---
Assigned To: unassigned
: location-framework-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-01-04 16:34 UTC by Tim Teulings
Modified: 2010-02-12 13:22 UTC (History)
3 users (show)

See Also:


Attachments
Patched example source from link given in bug report (5.62 KB, text/plain)
2009-11-12 23:54 UTC, Tim Teulings
Details
Makefile to quickly build example attachment (238 bytes, text/plain)
2009-11-12 23:55 UTC, Tim Teulings
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Tim Teulings (reporter) 2009-01-04 16:34:39 UTC
SOFTWARE VERSION:
liblocation-dev and liblocation packages of version 0.30-1

STEPS TO REPRODUCE THE PROBLEM:
Test application for liblocation as it can be found here
http://svn2.assembla.com/svn/TriageTag/gpsd-cli/trunk/src/main.c (not my code).
The code will be changed to use a custom GMainContext for GMainLoop, by adding:

/* After declaration of global variable "loop" */

GMainContext *context = NULL; /* Added! */        
GMainLoop *loop = NULL;       /* Unchanged! */

/* Creating custom GMaiNContext instance and assign it to our main loop */
        context=g_main_context_new();           /* Added! */        
      loop = g_main_loop_new(context, FALSE); /* Changed! */

EXPECTED OUTCOME:

Everything works. Especially callbacks get called.

ACTUAL OUTCOME:
After switching to a custom GMainContext callback are not called anymore.

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:
no special software

OTHER COMMENTS:
It seems like the implementation of liblocation relies on the default main
event loop of Gtk, based on the default GMainContext. If a custom context is
used internal "event handling" sends events to the wrong main loop resulting in
events getting lost.

I see no work around an the application side. This blocks usage of liblocation
for all applications not using the default context. This may especially block
usage of this library from non-Gtk applications. This may in fact also be a
problem for Qt applications (the problem with using the default context and
default main loop in this case is, that Gtk installs an callback that handles
X11 events conflicting with similar code in the other GUI framework).

Since liblocation does not seem to be free, I cannot check the code so this is
just an assumption. A possible fix is to make it possible for the application
to pass a custom GMainContext to the subsytsem. Note that using custom Context
seems to be allowed at other places of the maemo environment. For example
libosso allows to pass a custom context, too.

Any hints regarding a workaround will be apreciated.
Comment 1 Quim Gil nokia 2009-02-02 09:22:38 UTC
> EXPECTED OUTCOME:
> 
> Everything works. Especially callbacks get called.

FIXED in Fremantle.
Comment 2 Tim Teulings (reporter) 2009-11-12 23:54:05 UTC
Sadly given example (link and patch) still does not work with pre-production
device and final SDK. I will attach patched code and a simple makefile.

GPS daemon seems to get started by callbacks are never called. As said before
this may stop any non-gtk application from using liblocation. This may include
qt applications.

Funny that http://talk.maemo.org/showthread.php?t=33657 references
http://www.forum.nokia.com/piazza/wiki/images/7/7a/Qt_for_Maemo_Developers_Guide_v0_5_Beta.pdf
which in turn includes a Gtk example. I'm however positivly suprised that this
document also contains a link to my GPSJinni application. However because of
this bug I have problems getting it to work under fremantle (in diablo I used
liblocation for starting and stoping the daemon, but acces gps dameo diretcly
using libgps. However this is not possible anymore since the library is not
available in fremantle).
Comment 3 Tim Teulings (reporter) 2009-11-12 23:54:45 UTC
Created an attachment (id=1582) [details]
Patch example source from link given in bug report
Comment 4 Tim Teulings (reporter) 2009-11-12 23:55:20 UTC
Created an attachment (id=1583) [details]
Makefile to quickly build example attachment
Comment 5 Andre Klapper maemo.org 2009-11-17 13:17:14 UTC
Internal comment:
"Reason for this is that gconf in Maemo uses D-Bus and it is not possible to
change that to use non default main context (int-106889).
There is possible hack to iterate gconf maincontext manually but that will
drain battery and is not recommended."
Comment 6 Tim Teulings (reporter) 2009-11-17 22:58:02 UTC
(In reply to comment #5)

> "Reason for this is that gconf in Maemo uses D-Bus and it is not possible to
> change that to use non default main context (int-106889).
> There is possible hack to iterate gconf maincontext manually but that will
> drain battery and is not recommended."

So how than should Qt application access liblocation (since the possibly have
the same problem)? How does ovi-map do it?  They use GMainLoop, too - but
likely also with a custom context, or do they not (I had problems to use the
context of Gtk because Gtk then tries to filter events from my event loop)?

IT is also not true that DBus cannot use a non-standard context (or was it
meant that GConf cannot be made to use DBus with an non-standard context?)).
You can use 

          dbusSession=(DBusConnection*)osso_get_dbus_connection(context);
          dbusSystem=(DBusConnection*)osso_get_sys_dbus_connection(context);

to get DBus Connections for a non-standard context.

What now?

(..and how was this ticket ever set to FIXED in fremantle <grrr>?).
Comment 7 Andre Klapper maemo.org 2009-12-15 14:56:47 UTC
This is still being discussed...

The current, NOT RECOMMENDED workaround will iterate gconfs default maincontext
manually 10 times a second. You can pass GMainContext pointer to
LocationGPSDControl object with example g_object_set(G_OBJECT(control),
"maincontext-pointer", ctx, NULL);
Problem with this is power consumption since device can't sleep when having
timeout for iterating gconfs maincontext manually.
Comment 8 Tim Teulings (reporter) 2010-01-06 01:13:58 UTC
I was able to fix the problem in my software by switching to use the default
Gtk context. However since this is tricky I would still like to see this fixed
sometime in the future - at least as long libosso signal non-default context
usage is OK and documentaiton claims to not only support Gtk and/or Qt.
Comment 9 Andre Klapper maemo.org 2010-02-12 13:22:47 UTC
Internal comment:

"Workaround: Iterating default maincontext manually from software that uses
liblocation. Then iteration can be done as often as required. Then you have to
remember that some other applications might get/require fixes more often and
your application will get fixes only when you iterate default maincontext."

"The current behaviour is that custom GMainContext is iterated once a second.
This is a balance between functional correctness and battery. Application has
chance to iterate the context at any interval.
Basically, we see the current solution is the best working one, and no better
solution is available. -> CLOSED"