Tor,
Please commit the patch to HEAD as well as the stable branch. The
change looks fine to me. I will also get the unregister action tested
in the regular builds on the branches and perhaps in MacOS (I do not
know if it matters, but anyway!) as a routine but I do not expect any
surprises.
Tha
ah, okay.
Jeff
On Mon, 2006-06-19 at 17:03 +0300, Tor Lillqvist wrote:
> må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast:
> > Is there a ::destroy() method on the EShell object (like GtkWidgets)?
> > Perhaps it would be better to unregister there rather than in an idle
> > cb? My concern
må 2006-06-19 klockan 09:48 -0400 skrev Jeffrey Stedfast:
> Is there a ::destroy() method on the EShell object (like GtkWidgets)?
> Perhaps it would be better to unregister there rather than in an idle
> cb? My concern is that in the idle cb, there may still be a race?
Nah... The impl_finalize()
Is there a ::destroy() method on the EShell object (like GtkWidgets)?
Perhaps it would be better to unregister there rather than in an idle
cb? My concern is that in the idle cb, there may still be a race? Even
if not, tho, I feel it would be cleaner to unregister in a ::destroy()
if that's a possi
On Mon, 2006-06-19 at 00:18 +0300, Tor Lillqvist wrote:
> I think I have a good guess now: The problem is that all sockets by
> default are inherited by child processes in Windows. (Like file
> descriptors in Unix.)
Ah - we had some wonderful b-a-s bugs for the few sockets we didn't
CLOEX
må 2006-06-19 klockan 00:18 +0300 skrev Tor Lillqvist:
>I think it is possible to get the same effect as FD_CLOEXEC, though, by
> duplicating the socket using DuplicateHandle() to be non-inheritable,
> closing the original, and using the duplicated socket instead. Will have
> to try.
Indeed, work
lö 2006-06-17 klockan 02:23 +0300 skrev Tor Lillqvist:
> I should still of course also investigate why the other (unknown)
> mechanism which causes unregistration to happen anyway on Unix doesn't
> work on Windows...
I think I have a good guess now: The problem is that all sockets by
default are
lö 2006-06-17 klockan 01:40 +0300 skrev Tor Lillqvist:
> If my analysis is correct, this means that attempting to do a CORBA
> object unregistration in the GObject finalize method is too late, isn't
> it?
I tested by applying this simple patch to e-shell.c, moving the
bonobo_activation_active_ser
I am debugging why Evo on Windows doesn't manage to reuse the
evolution-data-server process that is left running when you quit
Evolution. One possible hint to the cause is that when you quit
Evolution on Windows, for some reason it seems that it doesn't manage to
unregister the EShell from the bono
