Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
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, works like a charm. I am a bit embarrassed now, though, that I so lightly had just ifdeffified the code in ORBit2 that does FD_CLOEXEC on the sockets, without really thinking what consequences there might be on Windows when sockets get inherited. Oh well. Luckily there doesn't seem to be that many uses of FD_CLOEXEC in the GNOME libs that I have ported, or Evo. Most of them are in code for functionality that is ifdeffed out for Windows completely anyway. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
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 CLOEXEC in the past. Of course, we still allowed b-a-s clients to inherit stdout/in/err (at least, until the g_spawn rework (?)) - but that is sometimes useful. HTH, Michael. -- [EMAIL PROTECTED] , Pseudo Engineer, itinerant idiot ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
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 possibility.
Jeff
On Sat, 2006-06-17 at 02:23 +0300, Tor Lillqvist wrote:
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_server_unregister() call from impl_finalize()
to notify_no_windows_left_idle_cb():
Index: shell/e-shell.c
===
RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
retrieving revision 1.272
diff -p -u -r1.272 e-shell.c
--- shell/e-shell.c 30 Jan 2006 11:49:53 - 1.272
+++ shell/e-shell.c 16 Jun 2006 23:17:50 -
@@ -360,13 +360,18 @@ static gboolean
notify_no_windows_left_idle_cb (void *data)
{
EShell *shell;
+ EShellPrivate *priv;
shell = E_SHELL (data);
+ priv = shell-priv;
set_interactive (shell, FALSE);
g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
+ if (priv-iid != NULL)
+ bonobo_activation_active_server_unregister (priv-iid,
+
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
bonobo_object_unref (BONOBO_OBJECT (shell));
return FALSE;
@@ -467,10 +472,6 @@ impl_finalize (GObject *object)
shell = E_SHELL (object);
priv = shell-priv;
-
- if (priv-iid != NULL)
- bonobo_activation_active_server_unregister (priv-iid,
-
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
e_free_string_list (priv-crash_type_names);
And lo and behold, it works! Now the ESHell gets unregistered, and when
starting Evolution again it manages to register its EShell and contact
the already running e-d-s etc.
OK to apply this patch to HEAD and stable? ChangeLog entry:
2006-06-17 Tor Lillqvist [EMAIL PROTECTED]
* e-shell.c (impl_finalize): Don't call
bonobo_activation_active_server_unregister() here, it's too late,
the EShell Bonobo object has already been deactivated and its
associated CORBA object is NULL.
(notify_no_windows_left_idle_cb): Instead, call
bonobo_activation_active_server_unregister() here, when the EShell
Bonobo object is still fully active.
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...
--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
--
Jeffrey Stedfast
Evolution Hacker - Novell, Inc.
[EMAIL PROTECTED] - www.novell.com
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
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() where the unregistration is currently done (but doesn't work) is called from the same notify_no_windows_left_idle_cb() function (through bonobo_object_unref()). --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
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 is that in the idle cb, there may still be a race? Nah... The impl_finalize() where the unregistration is currently done (but doesn't work) is called from the same notify_no_windows_left_idle_cb() function (through bonobo_object_unref()). --tml -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
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.
Thanks,
Harish
On Sat, 2006-06-17 at 02:23 +0300, Tor Lillqvist wrote:
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_server_unregister() call from impl_finalize()
to notify_no_windows_left_idle_cb():
Index: shell/e-shell.c
===
RCS file: /cvs/gnome/evolution/shell/e-shell.c,v
retrieving revision 1.272
diff -p -u -r1.272 e-shell.c
--- shell/e-shell.c 30 Jan 2006 11:49:53 - 1.272
+++ shell/e-shell.c 16 Jun 2006 23:17:50 -
@@ -360,13 +360,18 @@ static gboolean
notify_no_windows_left_idle_cb (void *data)
{
EShell *shell;
+ EShellPrivate *priv;
shell = E_SHELL (data);
+ priv = shell-priv;
set_interactive (shell, FALSE);
g_signal_emit (shell, signals [NO_WINDOWS_LEFT], 0);
+ if (priv-iid != NULL)
+ bonobo_activation_active_server_unregister (priv-iid,
+
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
bonobo_object_unref (BONOBO_OBJECT (shell));
return FALSE;
@@ -467,10 +472,6 @@ impl_finalize (GObject *object)
shell = E_SHELL (object);
priv = shell-priv;
-
- if (priv-iid != NULL)
- bonobo_activation_active_server_unregister (priv-iid,
-
bonobo_object_corba_objref (BONOBO_OBJECT (shell)));
e_free_string_list (priv-crash_type_names);
And lo and behold, it works! Now the ESHell gets unregistered, and when
starting Evolution again it manages to register its EShell and contact
the already running e-d-s etc.
OK to apply this patch to HEAD and stable? ChangeLog entry:
2006-06-17 Tor Lillqvist [EMAIL PROTECTED]
* e-shell.c (impl_finalize): Don't call
bonobo_activation_active_server_unregister() here, it's too late,
the EShell Bonobo object has already been deactivated and its
associated CORBA object is NULL.
(notify_no_windows_left_idle_cb): Instead, call
bonobo_activation_active_server_unregister() here, when the EShell
Bonobo object is still fully active.
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...
--tml
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()
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 inherited by child processes in Windows. (Like file descriptors in Unix.) Thus even if the Evolution process, which created the socket and was listen()ing on it dies, the socket still exists in LISTENING state as it has been inherited by the processes that Evolution has started (bonobo-application-server), even though said processes are blissfully unaware of it... This doesn't happen on Unix because ORBit2 sets FD_CLOEXEC on the sockets it creates. FD_CLOEXEC doesn't exist as such in Windows, so that code is just ifdeffed out, and I haven't really much thought about what consequences this might have... until now. 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. --tml ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
