Oh this is interesting - I hadn't thought about what would happen with the POA threading policies in the inproc case. I'm guessing they're being ignored and everything is handled on a single thread. And, since we're not using recursive mutexes it hangs when trying to lock the mutex for the second time.
Just to make sure, can you respond with a backtrace from the hang? This is kind of a sticky problem, since even if we fix this hang we'll end up with another one when the stack unwinds to the GNOME_Evolution_Addressbook_Book_open call, as the next line is a g_cond_wait call (from which it'll never wake). Michael, is there some way we can make the POA policies affect in-proc calls as well (if they don't already?) Chris On Thu, 2003-11-27 at 15:18, ERDI Gergo wrote: > 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 _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
