Re: gtkmozembed: why kill itself in destructor?
Hi, ext Marius Gedminas wrote: >>> kill (pid, SIGUSR1); >>> kill (pid, SIGKILL); >>> } >>> >>> Why shall we kill pid in the end? Can't the program exit normally? >> AFAIK it can be quite a bit faster. >> >> Normal process exit goes through a lot of destructor code, >> freeing things that are anyway freed by the operating system >> when process terminates. Browser is threaded, so maybe that >> the destructors use locking too... > > That's what the _exit() function from is for, isn't it? I guess it could be used instead. Maybe somebody wants to file a bug? (I think that unlike SIGKILL, debugger can catch _exit()) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtkmozembed: why kill itself in destructor?
On Wed, Jan 14, 2009 at 02:27:04PM +0200, Eero Tamminen wrote:
> ext Zhihai Wang wrote:
> > Deal all,
> >
> > In EmbedPrivate.cpp,
> >
> > EmbedPrivate::~EmbedPrivate()
> > {
> > sWindowList->RemoveElement(this);
> > sWidgetCount--;
> > mNeedFav = PR_FALSE;
> > if (mProgress)
> > mProgress->Shutdown();
> > if (mEventListener)
> > mEventListener->Shutdown();
> > mOwningWidget = nsnull;
> > if (sWidgetCount) return;
> > gboolean bval = FALSE;
> > if (gtk_moz_embed_common_get_pref
> > (G_TYPE_BOOLEAN,"gtkmozembed.no_destroy_on_last_window", &bval) && bval)
> > return;
> > int pid = getpid();
> > EmbedCommon::DeleteInstance();
> > EmbedGlobalHistory::DeleteInstance();
> > kill (pid, SIGUSR1);
> > kill (pid, SIGKILL);
> > }
> >
> > Why shall we kill pid in the end? Can't the program exit normally?
>
> AFAIK it can be quite a bit faster.
>
> Normal process exit goes through a lot of destructor code,
> freeing things that are anyway freed by the operating system
> when process terminates. Browser is threaded, so maybe that
> the destructors use locking too...
That's what the _exit() function from is for, isn't it?
Marius Gedminas
--
"Don't trust a statistic you haven't faked yourself."
-- Seen in another posting by Markus Kuhn
signature.asc
Description: Digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: gtkmozembed: why kill itself in destructor?
Hi,
ext Zhihai Wang wrote:
> Deal all,
>
> In EmbedPrivate.cpp,
>
> EmbedPrivate::~EmbedPrivate()
> {
> sWindowList->RemoveElement(this);
> sWidgetCount--;
> mNeedFav = PR_FALSE;
> if (mProgress)
> mProgress->Shutdown();
> if (mEventListener)
> mEventListener->Shutdown();
> mOwningWidget = nsnull;
> if (sWidgetCount) return;
> gboolean bval = FALSE;
> if (gtk_moz_embed_common_get_pref
> (G_TYPE_BOOLEAN,"gtkmozembed.no_destroy_on_last_window", &bval) && bval)
> return;
> int pid = getpid();
> EmbedCommon::DeleteInstance();
> EmbedGlobalHistory::DeleteInstance();
> kill (pid, SIGUSR1);
> kill (pid, SIGKILL);
> }
>
> Why shall we kill pid in the end? Can't the program exit normally?
AFAIK it can be quite a bit faster.
Normal process exit goes through a lot of destructor code,
freeing things that are anyway freed by the operating system
when process terminates. Browser is threaded, so maybe that
the destructors use locking too...
- Eero
on average free usually takes more time than allocation.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
