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

[Alexander Kirschner <alexander kirschner jambit com>]

Hi Jens,

thanks again for your reply - we recently upgraded to Qt 4.7.3 (which apparently includes the patch we were discussing about).

The threading-issues seem to be solved meaning the callbacks triggered by GUPnP now do arrive in the QThread that was used to initialize the GUPnPContext.

In our application only one thread uses GUPnP at a time, so basically we are single-threaded GUPnP-wise (but outside the main thread).

For creating the contexts on both device and control point we now call "gupnp_context_new(g_main_context_get_thread_default(), NULL, 0, NULL)" as you suggested (before our changes we passed NULL as first argument to "gupnp_context_new").

The crashes and assertions I reported in my previous emails did not occur since these changes... even with the pure evil Qt threading. :)

Again: Thank you for quick answers and for pushing us into the right direction - we will definetely observe your future work regarding the integration of Qt and GUPnP!


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: gupnp-list-bounces gnome org [mailto:gupnp-list-bounces gnome org] Im Auftrag von Jens Georg
Gesendet: Mittwoch, 29. Juni 2011 22:53
An: gupnp-list gnome org
Betreff: Re: AW: AW: Problem with GUPnP root device / Question regarding GUPnP deinitialization

On Mi, 2011-06-29 at 19:01 +0200, Alexander Kirschner wrote:

> 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.

<rant>
Qt's threading is pure evil. It suggests a convenience it can't deliver
in the end.
</rant>

That said, usage of GUPnP in threads isn't that common, it might be that
you hit a code path no one has hit before, although if I got your
description correctly, it's still single-threaded, just not in main
thread?

> 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). 

Huh? even with the asynchronous functions? That would be weird.

 - Do you pass a main context to gupnp_context_new() or
   gupnp_context_manager_new()? If you don't, everything will use the 
   default context which is the one of the main thread.

 - Can you check if your version of Qt has the patch from the Qt bug I 
   linked to? If you have the patch, you can simply pass 
   g_main_context_get_thread_default () here and the event should end 
   up in your worker thread's main loop. If not, I need to think   
   about an alternative method.

> 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(...)).

See above, about main context.

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

In general, having a worker thread that does the UPnP lifting should be
fine. I'm not sure if you'd need to. QtSparql e.g. integrates (async)
GLib functions with Qt just fine.

If you can't disclose the code, can you boil it down to an example
application that shows the same behaviour? That would help debugging a
lot.


_______________________________________________
gupnp-list mailing list
gupnp-list gnome org
http://mail.gnome.org/mailman/listinfo/gupnp-list