Re: Opening dialogs outside the Gtk thread?

[Matthias Kaeppler <matthias finitestate org>]

Dmitry Konyshev wrote:
> When the lockup actually happens? You mustn't use the lock in the 
> dialog's event handlers, 'cause they get called in context of the main 
> thread with the lock already acquired.

No, it's happening in a gnome-vfs signal handler. No Gtk lock is 
acquired there.

> Nau is open source, isn't it? You could take a look at the sources and 
> find out everything you need to know ;)
>
> If you show a part of the code you're talking about, probably you get a 
> more helpful advice on it.

As I said, I have read the source code in question, as well as the eel 
sources of the dialog functions which are used and I couldn't find 
anything related to locking or unlocking. Here are the relevant parts of 
 the Nautilus source which involve showing a message dialog in a signal 
handler which is called from the async transfer functions running in a 
separate thread:


handle_transfer_overwrite (const GnomeVFSXferProgressInfo *progress_info,
		           TransferInfo *transfer_info)
{
	int result;
	char *text, *primary_text, *secondary_text, *formatted_name;
	gboolean is_merge, target_is_dir;

	nautilus_file_operations_progress_pause_timeout 
(transfer_info->progress_dialog);	

	... snipped handling of some special cases here
	
	/* transfer conflict, prompt the user to replace or skip */
	formatted_name = format_and_ellipsize_uri_for_dialog (
		parent_for_error_dialog (transfer_info), progress_info->target_name);


        ... snipped some text formatting here	


	if (progress_info->duplicate_count == 1) {
		/* we are going to only get one duplicate alert, don't offer
		 * Replace All
		 */
		result = eel_run_simple_dialog
			(parent_for_error_dialog (transfer_info),
			 TRUE,
			 GTK_MESSAGE_QUESTION,
			 text,
			 secondary_text,
			 _("Conflict While Copying"),
			 _("_Skip"), _("_Replace"), NULL);
		g_free (text);	

		nautilus_file_operations_progress_resume_timeout 
(transfer_info->progress_dialog);
					
		switch (result) {
		case 0:
			return GNOME_VFS_XFER_OVERWRITE_ACTION_SKIP;
		default:
			g_assert_not_reached ();
			/* fall through */
		case 1:
			return GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE;
		}
	} else {
		result = eel_run_simple_dialog
			(parent_for_error_dialog (transfer_info), TRUE, GTK_MESSAGE_QUESTION, 
text,
			 secondary_text,
			 _("Conflict While Copying"),
			 _("Replace _All"), _("_Skip"), _("_Replace"), NULL);
		g_free (text);

		nautilus_file_operations_progress_resume_timeout 
(transfer_info->progress_dialog);

		switch (result) {
		case 0:
			return GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE_ALL;
		case 1:
			return GNOME_VFS_XFER_OVERWRITE_ACTION_SKIP;
		default:
			g_assert_not_reached ();
			/* fall through */
		case 2:
			return GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE;
		}
	}
}

As you can see, no gdk_threads_enter() or gdk_threads_leave(). I also 
read the source code of eel_run_simple_dialog() but it doesn't involve 
dispatching signals to the main thread or anything else related to 
threading.

Regards,
Matthias