cancel_update in NautilusInfoProviderIface and possible race condition

[Stian Skjelstad <stian nixia no>]

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.




Stian Skjelstad