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

[Krishna R]

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_ZERO(&readSet);
    FD_SET(socketfd, &readSet);

    while(1)
    {
        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.
--K

On 1/26/07, Havoc Pennington <hp at redhat.com> 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...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070126/24e33375/attachment.html