Re: [Evolution-hackers] Something screwy when Evolution Shell invokes bonobo_activation_active_server_unregister()

2006-06-19 Thread Tor Lillqvist
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()

2006-06-19 Thread Michael Meeks

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] mmap() for the summary file

2006-06-19 Thread Florian Boor
Hi,

[EMAIL PROTECTED] wrote:
 H... I am not really convinced yet; I mean even when I have
 100 mails with the same email address in my Inbox (which seems 
 a lot from one person!). The email-address would be 20 chars; now having
 'm all in one string saves me, even in this extreme case, only
 about 2Kb, event forgetting about the overhead of the hash tables etc.

as long as we talk about individual senders this is true, but if you think about
 mailinglists and all this automated server notifications this could save quite
some memory. As long as it is possible to implement this without a too big
effort and code overhead it would be useful. Of course - even saving 100kb which
would be optimistic for a huge mailbox is not be worth to mention on a modern
PC - but on a mobile device that would be nice to have.

Greetings

Florian

-- 
The dream of yesterday  Florian Boor
is the hope of todayTel: +49 271-771091-14
and the reality of tomorrow.Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904][EMAIL PROTECTED]

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] mmap() for the summary file

2006-06-19 Thread Philip Van Hoof
On Mon, 2006-06-19 at 11:56 +0200, Florian Boor wrote:

 as long as we talk about individual senders this is true, but if you think 
 about
  mailinglists and all this automated server notifications this could save 
 quite
 some memory. As long as it is possible to implement this without a too big
 effort and code overhead it would be useful. Of course - even saving 100kb 
 which
 would be optimistic for a huge mailbox is not be worth to mention on a modern
 PC - but on a mobile device that would be nice to have.

But the complexity for getting this *in* the file that is to be mmap'ed
does increase then. Also the backward compatibility is undoable this
way.

You'll need to implement some sort of hash-table with pointers to
strings at the beginning of the file, hash-keys in the summary tree
itself. And the strings at the end of the file.

Agreed that this would dramatically increase loading time (the time
needed to seek/walk-a-pointer over the entire mmap()ed file and create
summary-info structs). As it would decrease the amount of data that is
to be mmap()ed. 

I agree this is worthwhile for the current read() to memory
implementation. I don't think the complexity is going to payoff in real
improvements for a mmap() implementation of it. But I would,
nevertheless, be very interested in the experiment.

Note that there's an mmap() on Windows and that glib abstracts it with
some glib API. I would of course use the glib abstraction API for this.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be

___
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()

2006-06-19 Thread 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? 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()

2006-06-19 Thread Tor Lillqvist
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()

2006-06-19 Thread Jeffrey Stedfast
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()

2006-06-19 Thread Harish Krishnaswamy
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