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

[Jens Georg <mail jensge org>]

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.