DBus Threading in a Late-loading module

[Thiago Macieira]

Nate Nielsen wrote:
>Which is risky, since a PKCS#11 module may be loaded by the OS (eg:
>Solaris) or by massive beasts like Mozilla's NSS.
>
>As I look at this further, it seems that I'll have to go cold turkey as
>far as libraries. Both DBus and Glib require threading to be explicitly
>initialized, and due to late loading of the module, I can't use either.

I posted this in 
http://lists.freedesktop.org/archives/dbus/2007-February/007111.html:

====
There are other issues that involve shared connections. We discussed them 
in IRC another day and I think it would be a good idea to bring them 
here. When using a shared connection, how/when does one set up the 
DBusWatch and DBusTimeout callbacks?

I.e., do we depend on a binding to do that? Or should the application 
itself add those callbacks? What if it's a library?

Whoever does so, if it's not the application, what should it do when it no 
longer needs D-Bus? Is it mandated that it keep the callbacks until the 
program exits? What happens if it was a plugin that is about to be 
unloaded from memory?

I see no solution short of dropping those functions and knowing the main 
loop ourselves.
====

That was about DBusWatch and DBusTimeout, but it applies somewhat to 
threading too. In fact, if we solve the problem of the mainloop 
integration, we solve the problem of threading too.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070402/c2bed6e6/attachment.pgp