Re: cancel_update in NautilusInfoProviderIface and possible race condition

[Alexander Larsson <alexl redhat com>]

On Fri, 2007-11-09 at 15:44 +0100, Stian Skjelstad wrote:
> I'm playing with the infoprovider interface and I want to make things
> async (since some external operations I do can take some fair amount of
> time).
> 
> So here is the deal:
> 
> I receive a call via NautilusInfoProviderIface->update_file_info which
> gives me info that I send to another thread, and I return
> NAUTILUS_OPERATION_IN_PROGRESS;
> 
> 
> Now lets say that the nautilus sends me a
> NautilusInfoProviderIface->cancel_update, and the thread is scheduled
> out and the worker thread from above schedules in, calls up
> nautilus_info_provider_update_complete_invoke and deletes the handle
> 
> now the cancel_thread is scheduled back and now the handle points to
> invalid memory.
> 
> 
> How is this supposed to be handled? Should I have a managed list that is
> locked with a mutex that contains all valid handles, and if I receive a
> cancel_update on a handle that no longer exists in the list, I should
> ignore it? Or does the nautilus developers have other toughts about this
> issue? Nothing is mentioned in the docs.

The NautilusInfoProviderUpdateComplete should happen from the main
thread, not your i/o thread. You normally achieve this by queueing it
with g_idle_add. This casues serialization of the cancel/update calls
(the nautilus core will never call cancel if the callback has happened
on the main thread) and this way you should be able to handle all
problems like the one described above.