AW: AW: Problem with GUPnP root device / Question regarding GUPnP deinitialization

[Alexander Kirschner <alexander kirschner jambit com>]

Hi Jens,

so unfortunately we don't have the time to wait until this GObject-introspection-thing is ready. :) Until then I guess we have to get it going on our own.

Your suggestions for our problems to result from race conditions or unitialized structures both sound reasonable, but for now we couldn't find anything.

Our debugging for today led us to printf()-statements deep within glib, especially g_object_new()... no results so far.

Right now we suspect the integration of the GObject-System into the Qt-world to be our main problem - especially the threading part.

In our application all calls to GUPnP-specific functions are done within a simple QObject which gets moved by Qt's moveToThread-method into a separate QThread. We are doing this because otherwise GUPnP and our main thread would produce deadlocks (e.g. when a user interaction within the UI leads to calls to GUPnP). We observed that GUPnP-callbacks (e.g. "device-proxy-available") arrive in QT's main thread. All calls to this QObject are decoupled using Qt's signals and slots (QMetaObject::invokeMethod(...)).

Do you see any problems in our architecure? How would you separate GUPnP-code from Qt-code?


Thanks in advance & Best Regards,

Alex

-- 
Alexander Kirschner M.Sc., Software Architect
Phone: +49.89.45 23 47-232
PGP-Fingerprint: 98EC 0735 04F7 3FF5 E8F3  E5B1 B836 D6D0 C5B1 5BEA


-----Ursprüngliche Nachricht-----
Von: Jens Georg [mailto:mail jensge org] 
Gesendet: Mittwoch, 29. Juni 2011 09:21
An: Alexander Kirschner
Cc: gupnp-list gnome org
Betreff: Re: AW: Problem with GUPnP root device / Question regarding GUPnP deinitialization

On Di, 2011-06-28 at 19:39 +0200, Alexander Kirschner wrote:
> Hi Jens,
> 
> thank you for your quick reply! I read about your project dealing with combining Qt and GUPnP. What is your experience on that matter?

I had to stop due to some problems with bindability which are now
resolving slowly, the last major trouble-spot I'm seeing is the
ResourceFactory since it is very GObject/GType centric.

Also hopefully at some point Richard Dale's introspection-based Qt
bridge for GObject libraries will be usable...

> 
> Yes, we are actually combining GUPnP and Qt... in Qt 4.7.1 there is still an issue that the GUPnP context is running in the Qt main thread (no other thread can be assigned); but this seems not to be a problem for now (and will apparently be fixed in Qt 4.8... are you involved in this?).

I'm kind of involved, but for reasons not related to GUPnP at all. I
suspect you mean http://bugreports.qt.nokia.com/browse/QTBUG-14425 ?

That wouldn't really help you with current GUPnP versions, they need to
be associated with a context anyway, so you would need to pass
g_main_context_get_thread_default() manually. We are working on a series
of patches that deprecates the explicit main_context and uses
g_main_context_get_thread_default() instead. So with Qt 4.8 and the
upcoming development release it should finally work OOTB.

> 
> By "deinitializing/initializing" GUPnP I meant shutting down and restarting UPnP root device and control point without shutting down our enclosing Qt application. We simply weren't sure if calling "g_object_unref" with main context as param is sufficient and also unregisters the signal handlers.

Well it depends. GObjects are reference-counted. So if you call
g_object_unref and it had a reference count of 1, the object will be
destroyed and all signal handlers disconnected. If it was >1, only the
reference count will be decreased and all signal handlers stay. Think of
QSharedPointer, with the difference that it works ;)

For temporarily disabling a context (which then disables all associated
devices/controlpoints etc.) I'd suggest to use g_object_set
(control_point or context, "active", FALSE, NULL);


> We reran some tests using valgrind... nothing suspicious. Using valgrind with --leak-check=full (as always) leads to a lot of leak-hints including libsoup, but we don't think the problem is related to these leaks. The funny thing is that running our tests within valgrind enhances our stability dramatically (no crashes so far).

So most likely it's a race condition. Is your project open source?

> 
> Besides the trace I already mentioned in my last email we often get this error...
> 
> (<unknown>:8573): GLib-GObject-WARNING **: invalid uninstantiatable type `<invalid>' in cast to `GUPnPDeviceInfo'
> ** (<unknown>:8573): CRITICAL **: gupnp_device_info_get_udn: assertion `GUPNP_IS_DEVICE_INFO (info)' failed
> 
> ... any suggestions?

No, not really. I suspect there's something fishy going on inside your
code, like you missed to initialize something.