Re: Opening dialogs outside the Gtk thread?



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]