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 `---= [EMAIL PROTECTED] =---' 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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 `---= [EMAIL PROTECTED] =---' Speak the truth, but leave immediately after. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
