[Evolution-hackers] Re: Strange console messages when accessing e-d-s through the libecal C API

On 8/23/05, michael meeks <michael meeks novell com> wrote:
> On Tue, 2005-08-23 at 18:12 +0200, vseguip gmail com wrote:
> > I can actually make the message disappear by putting a "sleep(1)"
> > before the function
> > bonobo_debug_shutdown(). Could it be some sort of race condition that
> > only hits us when we exit in some special way (it sometimes doesn't
> > print the statement even if I don't put the sleep, specially if it's
> > the first time I exec the program) or when we don't use the
> > bonobo_main loop ?
>         Right - I guess in which case then that there is 'oneway' data left
> lurking around in the socket buffer - waiting to be sent to the other
> end.
I've tracked down the message to the CORBA_ORB_Shutdwn:

void CORBA_ORB_shutdown (CORBA_ORB           orb,
		    const CORBA_boolean wait_for_completion,
		    CORBA_Environment  *ev)
	PortableServer_POA root_poa;

	root_poa = g_ptr_array_index (orb->adaptors, 0);
	if (root_poa) {
		PortableServer_POA_destroy (
			root_poa, TRUE, wait_for_completion, ev);
		if (ev->_major) {
			if (wait_for_completion)
				g_warning ("FIXME: wait for "
					   "completion unimplemented");

	giop_shutdown ();

	ORBit_ORB_shutdown_servers (orb);

Is this the flag you were referring previously? Is there a way to
flush the data?

>         Unfortunately clean shutdown is a nasty problem - inasmuch that in
> order to send a msg you may need to recieve one ;-) - ie. if as you
> shutdown you block recv's the other end may block sending & thus not be
> able to process your outgoing data. Anyhow ;-) so - the ORB needs to
> switch into a different buffer-flushing mode, that immediately closes
> connections that get opened to it, or replying with system exceptions,
> at the same time trying to flush it's outgoing oneway buffers :-)
>         That's what the message means at least.
All I can say is :-O !

Given the fact that a patch on Orbit does not look probable, what
would your advice on the issue be? Just use the sleep workaround or
could there be a better way?

 I've actually thought of running bonobo_main in an atexit function
and then running bonobo_quit_main in a g_idle function. If this
manages to avoid the message  I would try to hook this in the ruby
interpreter and see if it doesn't explode.

 V. Seguí

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]