Signals & threads - low level C API [Newbie question]

Krishna R sith.list at
Fri Jan 26 14:54:54 PST 2007

Thanks that makes sense. The select method blocking on the readset of the
sockets for rcving thread works fine. The documentation says DO NOT use
get_socket and use DBUSWatch, but i guess  i am ok since this is a simple
app and only this thread is recving data and there is no main loop etc?

This what i had to do...if there are other newbies trying the same thing...

    // Get the socket descriptor of dbus connection of this process
    if (!dbus_connection_get_socket(pConnection,&socketfd)){

        return NULL;

    FD_SET(socketfd, &readSet);

        retVal = select(socketfd+1, &readSet, NULL, NULL, NULL); // block

        if (-1 == retVal) // The socket might no loger be available
            if (!dbus_connection_read_write_dispatch (pConnection, 0))
                // If this returns FALSE, the connection is disconnected
                // and we dont want to spin in this loop forever
                return NULL; // exit from thread


        else if (FD_ISSET(socketfd, &readSet))
            dbus_connection_read_write_dispatch (pConnection, 0);

Thanks for your help again.

On 1/26/07, Havoc Pennington <hp at> wrote:
> Krishna R wrote:
> > Do i still need the main loop you are talking about in the above simple
> > scenario?
> >
> The problem is that there's a lock on the socket. When
> read_write_dispatch() blocks, it will hold this lock. That means
> dbus_connection_flush() can't acquire it in order to flush.
> You can imagine various libdbus fixes to make it smarter about this
> situation, but if you don't want to hack on libdbus you probably have to
>   only call read_write_dispatch() when you know it won't block, which is
> normally done with a main loop as Thiago suggests. As a hack you could
> also just call dbus_connection_get_socket() and poll()/select() on it
> manually in a simple loop.
> An even worse hack would be to try and wake up the poll by creating an
> EINTR (raise some bogus signal), but I don't know if that will work and
> it probably isn't that portable across unix flavors if it does.
> Another bad hack would be to put a short timeout on the
> read_write_dispatch so it never blocks too long.
> Havoc
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the dbus mailing list