Closing old connection after fork (Python)

Jami Pekkanen jami.pekkanen at nokia.com
Wed Aug 22 06:59:37 PDT 2007


On Wed, 2007-08-22 at 09:19 -0400, ext Havoc Pennington wrote:
> Hi,

Hi, thanks for the fast answer.

> It isn't 100% clear to me how you're doing this and what's breaking,
> but in general
> the DBusConnection in the end is a socket file descriptor. I *think* it has the
> close-on-exec flag set, so if your child exec'd it should be closed.
> If you just fork
> though, then both parent and child would have a copy; and I don't think anything
> sane can possibly happen in that context, since two processes will be
> trying to read and write from the same connection socket.

This is what I assumed also, so I tried to close the parent connection.
In Python however destroying an object isn't a very simple task and
closing the connection using Python's API also sends release messages to
the bus causing also the main thread to stop receiving calls.

The behavior does seem to be consistent with your description, as the
messages get received randomly in all threads sharing the connection
object.

> Maybe it's as simple as in the child, be sure to create a *private*
> bus object with dbus_bus_get_private(), which means you'll open a new
> descriptor instead of potentially re-using the parent one (or is this
> already what the True in SessionBus(True) does in python?)

Yes, the True-argument makes the bus connection private. And the private
bus is working quite well. Its just the connection from parent which
keeps haunting.

> But you'd still have to be very careful not to touch the shared
> connection from the parent, if any, and disable any main loop setup on
> the child's copy of the shared connection.

I tried this also, but the main loop interaction at least in the Python
API is quite weird and I didn't find a mechanism to explicitly define a
new loop to use.

> I don't know about this whole line of development though... fork()
> without exec() is pretty tricky, you are very likely to be better off
> with threads or some other architecture.

I just came to same conclusion and I'm changing the architecture to use
exec. I think it should work however, because in this application the
main process is quite simple and well defined.

Thanks
- Jami Pekkanen



More information about the dbus mailing list