[maemo-developers] gtkmozembed: why kill itself in destructor?
From: Eero Tamminen eero.tamminen at nokia.comDate: Wed Jan 14 14:27:04 EET 2009
- Previous message: gtkmozembed: why kill itself in destructor?
- Next message: gtkmozembed: why kill itself in destructor?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message: gtkmozembed: why kill itself in destructor?
- Next message: gtkmozembed: why kill itself in destructor?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
