[packagekit] Python fork() question

[Richard Hughes]

On Sat, 2008-03-01 at 22:15 -0500, Robin Norwood wrote:
> When I open pk-application, go to the groups tab, and click one after
> the other, I quickly get into a situation where the backend signals the
> next SearchGroup command before the thread that performed the last one
> has finished exiting.

Well, the daemon only queues the next transaction after finished has
been sent, and then to be kind waits 50ms (pk_backend_finished_delay).

> We certainly don't want two threads messing in
> the yum DB at the same time

Totally.

> However, with this logic, I eventually get this error:
> 
> """
> The backend took too much time to process the synchronous request - you
> need to fork!
> """

Sure, the backend shouldn't be waiting, and this is a self-check in the
daemon to make sure the backend isn't doing anything insane and blocking
on the sync request (which would block the UI of the client program).

> I'm not really sure why it takes so long (1 s?) for the child process
> to exit...it exits right after calling Finished() - the yum is already
> unlocked and everything.

It takes one second to exit?! Is this normal - in which case, can we
detect it?

> It doesn't ever seem to take more than a second or two, so perhaps we
> could just have the daemon wait a little longer...

/**
 * PK_BACKEND_FINISHED_TIMEOUT_GRACE:
 *
 * The time in ms the backend waits after receiving Finished() before
 * propagating the signal to the other components.
 * This delay is required as some threads may take some time to cancel or a
 * spawned executable to disappear off the system DBUS.
 */
#define PK_BACKEND_FINISHED_TIMEOUT_GRACE	50 /* ms */

Can you try changing that to 2000 in pk-backend.c pls.

> Any ideas, smart people?

Well, we need to find out why the thread takes over a second to quit
after we've done Finished - what is the process/thread actually doing?
Can we strace it? I really don't like the idea of leaving
PK_BACKEND_FINISHED_TIMEOUT_GRACE so high, as it'll slow down the queue
processing pretty dramatically.

> The good news is, other than this, the new backend seems to be working
> well.

Excellent :-)

Richard.