[Evolution-hackers] Deadlock when accessing an in-proc address book (fwd)

[ERDI Gergo <cactus cactus rulez org>]

I'm re-sending this because I wasn't subscribed when I sent it initially

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
Define (n.)  De ting you get for breaking de law.

---------- Forwarded message ----------
Date: Thu, 27 Nov 2003 17:46:01 +0100 (CET)
From: ERDI Gergo <cactus cactus rulez org>
To: evolution-hackers lists ximian com
Subject: Deadlock when accessing an in-proc address book

Hi,

I'm looking at http://bugzilla.gnome.org/show_bug.cgi?id=127535, but there
seems to be a deadlock problem. 
If e.g. e_book_load_uri is called by a calendar backend (which resides in
evolution-data-server, so the addressbook provider is going to be in the
same process), the flow of events eventually gets to the point where it
sends a BookOpen notification to listeners, and there's an in-proc
listener for it.

However, e_book_load_uri locks a mutex near line e-book.c:1700:
(simplified code by removing error checking)

	our_op = e_book_new_op (book);

	g_mutex_lock (our_op->mutex);
	corba_book = GNOME_Evolution_Addressbook_BookFactory_getBook
			(factory, book->priv->uri, 
			 bonobo_object_corba_objref (BONOBO_OBJECT (book->priv->listener)), 
			 &ev);
	GNOME_Evolution_Addressbook_Book_open (corba_book,
					       only_if_exists,
					       &ev);

	/* wait for something to happen (both cancellation and a
	   successful response will notity us via our cv */
	g_cond_wait (our_op->cond, our_op->mutex);

	status = our_op->status;

	/* remove the op from the book's hash of operations */
	e_book_clear_op (book, our_op);

GNOME_Evolution_Addressbook_Book_open eventually leads to
e_data_book_respond_open, which does the actualy firing of the
notifyBookOpened one-way CORBA method.

And this is where the problem starts. For the in-proc case, the server's
impl_notifyBackendOpened method gets called instantly, and the way it's
implemented is that it emits a GSignal that is connected to
e_book_response_open (which is near e-book.c:1360). And here's the code
for e_book_response_open (again, simplified):

	EBookOp *op = e_book_get_op (book);

	g_mutex_lock (op->mutex);

	op->status = status;

	g_cond_signal (op->cond);
	g_mutex_unlock (op->mutex);

So it waits for op->mutex which is locked by e_book_load_uri.
This doesn't cause a deadlock for the out-of-proc case because then,
notifyBookOpened returns instantly (due to its oneway nature) and thus the
mutex is unlocked by e_book_load_uri by the time e_book_response_open is
called.

I hope the above is a detailed enough explanation of the problem that
someone can help me in solving it. 

Thanks,
	Gergo

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
Speak the truth, but leave immediately after.