Re: [Nautilus-list] gnome-vfs async race condition

[Maciej Stachowiak <mjs eazel com>]

Martin Baulig <martin home-of-linux org> writes:

> 
> The problem is the following:
> 
> * in frame #13, Nautilus calls gnome_vfs_async_get_file_info() which launches
>   a new GnomeVFSSlave and this results in an invocation of the GLib main loop.
> * at the time the GLib main loop is entered, *handle_return is not yet written
>   so (in start_getting_file-info) directory->details->get_info_in_progress is
>   still NULL.
> * inside the main loop we may get an event which results in
>   start_getting_file_info() on the same directory being called - and here
>   comes the problem: since gnome-vfs hasn't assigned us a handler yet, we
>   call gnome_vfs_async_get_file_info() on the same directory again.
> 

This is really funny because I was just telling Pavel on IRC how
invoking the main loop from random code would lead to race conditions
that would cause crashes, and he was not entirely convinced this would
apply to where it was getting used in gnome-vfs. Thanks for the timely
example. :-)

> 
> IMO the best way to fix this problem is to always write *handler_return
> before starting any async operations everywhere in gnome-vfs-async-ops.c.
> 
> What do you think ?

That might fix this specific race, but I think in general it's safer
to avoid invoking the main loop.

> (Btw. is there a gnome-vfs mailing list or where is the correct place to
>  discuss such things ?)
> 

<gnome-vfs helixcode com>

Thanks for the detailed analysis here, BTW.

 - Maciej