Re: [Evolution-hackers] My ORBit2 Win32 problem today

[Michael Meeks <michael meeks novell com>]

Hi Tor,

On Wed, 2006-06-21 at 02:35 +0300, Tor Lillqvist wrote:
> I spent much time today debugging a problem related to
> evolution-exchange. When quitting Evolution, and then after a while
> starting it again, it hang. bonobo-activation-server was waiting for a
> reply from evolution-exchange-storage.exe (which had been staying around
> even after Evolution quit).

	Ah - good ;-) glad it was nothing to do with some threading problem in
the ORB.

> Well, the root cause why it didn't go away was the atexit() call in
> ORBit2's CORBA_ORB_init(). (Well, g_atexit(), but that is just a #define
> for atexit() in Win32.)

	So - as the comment says, this is primarily for cleaning up stale
sockets in /tmp/orbit-$USER on Unix - which (since we don't use
anonymous sockets) can't be cleaned up any other way, and otherwise tend
to build up into a mountain of stale sockets [ incidentally run
linc-cleanup-sockets on a Unix box to see how many apps pathalogically
failed in recent history without that cleanup ;-)

michael t60p:/data/home/michael> linc-cleanup-sockets
Cleaned 379 files 24 still live

	[ but I do a lot of ctrl-c exiting ;-) ]

> So, I simply ifdeffed out the atexit() usage on Windows... Just let the
> process die

	Sounds reasonable; of course: ultimately if we didn't create any UNIX
sockets we don't badly need this atexit thing to clean them up :-) so
life is good. There is however another interesting problem that the
g_atexit [ might ] solve: which is that sockets can behave quite
strangely: eg. a remote app can close a socket / exit and the client may
not (remote machine only?) get notification that the socket is shut/dead
until it tries to use it. b-a-s eg. is lifecycle managed by noticing
when it's clients die, and when they all go - it goes too; of course,
potentially if the ORB is shutdown cleanly it can send
'close-connection' messages on all it's connections 1st [ I hope /
imagine it does this, although the shutdown semantics are a little
unpolished pwrt. 'wait-for-completion' ]. Anyhow - *hopefully* the local
TCP sockets you're using will be helpful and wake a poll(HUP) [ or
whatever you use ] when a remote app exits, and there is no problem here
either - if so, we should prolly just commit that #ifdef to HEAD
ORBit2 :-)

> A safe way around this would be to explicitly flush and shut down CORBA
> and Bonobo before exiting main() in evolution-exchange/storage/main.c.
> Unfortunately I couldn't find any API to do that cleanly. Calling
> bonobo_debug_shutdown() (twice, as bonobo_init_full() apparently gets
> called twice and bonobo_debug_shutdown() needs to be called as many
> times to actually do anything...) causes a g_error() from
> bonobo_context_shutdown(): "In-proc object has no servant association
> this probably means you shutdown the ORB before you shutdown libbonobo".
> I wonder if that is a bogus error message?

	How odd. Of course, could be a bogus error message - please do chase
it.

> - There is no absolute need any longer to kill the processes that stay
> running when one quits Evolution, or to clean out state files.

	Great. I assume that when you log-out that the alarm daemon, gconfd-2
and b-a-s all get cleaned up by the O/S ?

	Anyhow - good work :-)

	Regards,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot