[Evolution-hackers] bonobo_main thread ...

[Michael Meeks <michael ximian com>]

Hi guys,

	Just debugging a deadlock of some sort (perhaps the ORB not reporting a
dead connection exception somehow [possibly] when e-d-s crashes). Anyhow
- I see (again) in my trace this:

Thread 3 (Thread 16386 (LWP 29821)):
#0  0x413e6b94 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0
#1  0x413e69d8 in __pthread_wait_for_restart_signal () from /lib/i686/
libpthread.so.0
#2  0x413e2e90 in pthread_cond_wait GLIBC_2 0 () from /lib/i686/
libpthread.so.0
#3  0x415d528f in g_main_context_wait () from /usr/lib/libglib-2.0.so.0
#4  0x415d6ce7 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#5  0x4077c8b7 in bonobo_main () from /opt/gnome/lib/libbonobo-2.so.0
#6  0x41a8a026 in startup_mainloop (arg=0x0) at e-book.c:2346
#7  0x413e3f60 in pthread_start_thread () from /lib/i686/libpthread.so.0
#8  0x41710327 in clone () from /lib/i686/libc.so.6

	And I wonder what crack is this ? why do we have a thread sitting there
running 'bonobo_main' ? - of course, hopefully we'll enter the glib
mainloop in the main process (blocking that thread from getting access
to the context on the condition) before anything too bad happens in that
thread - but; what is the thinking here ? and/or why was that added ? it
looks hyper-odd to me.

	Thanks,

		Michael.

-- 
 michael ximian com  <><, Pseudo Engineer, itinerant idiot