[Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
- From: Jamie McCracken <jamiemcc blueyonder co uk>
- To: � Dejean <benoit placenet org>
- Cc: Thomas Vander Stichele <thomas apestaart org>, "Gustavo J. A. M. Carneiro" <gjc inescporto pt>, desktop-devel-list gnome org, Deskbar Applet List <deskbar-applet-list gnome org>
- Subject: [Deskbar] Re: Gnome 2.14 Module Proposal: Deskbar Applet
- Date: Thu, 27 Oct 2005 15:39:04 +0100
Beno�Dejean wrote:
Le jeudi 27 octobre 2005 �3:32 +0100, Gustavo J. A. M. Carneiro a
�it :
Qui, 2005-10-27 �11:05 +0200, Beno�Dejean escreveu:
The result: a single process (per user, per display), and a single
main loop, for all applets. Of course this means if one applet
deadlocks or dies, they all die. But at least dying in python is not so
easy. You usually get only an exception that is ignored. Deadlock is
easier if they use threads.
We don't do it for C applets because if "one applet deadlocks or dies,
they all die". But thanks for raising the problem of many VM-based
applets : currently, 3 applets would take ~ 50MB of RES memory.
Yes the real problem with panel applets is that they are out of process
apps which regardless of the language they are written in are always
going to be inefficient memory wise to some degree even when written in C.
The best solution is to run all panel apps in-process in their own
threads (IE make a panel applet a GTKWidget that's threadsafe). We also
get rid of Corba/bonobo by doing so which is always a plus. The
drawbacks as stated should not really be a problem if the applets are
properly debugged (at least so they dont seg fault)
--
Mr Jamie McCracken
http://www.advogato.org/person/jamiemcc/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]