[maemo-developers] python2.5 - unnecessary multiple processes forked

[From: Jayesh Salvi]

I tried Lauro's C example in scratchbox environment and see that it's indeed
forking 4 more processes. So this is not a python problem. This problem's
root cause seems to reside in the widget library. I can't imagine any valid
reason for gtk/hildon to fork more processes just to show a GUI dialog. Does
anyone know?

On 12/31/07, Martin Grimme <martin.grimme at gmail.com> wrote:
>
> Especially make use of gc.collect() after you have worked with
> gdk.Pixbuf objects. They won't free their memory otherwise. It's a
> good habit to free unused Pixbufs with del and run the garbage
> collector afterwards.
> And be aware that if a class overrides the __del__ method (some sort
> of destructor), it won't be freed by the garbage collector at all.
>
>
> Cheers,
> Martin
>
> 2007/12/31, Alex Iliadis <alex at immunityinc.com>:
> > I recommend using the garbage collector module manually to override the
> > defaults. Python for some reason doesn't reclaim memory fast. So if you
> > put in your code:
> > import gc
> > gc.collect()  (at the right spots, probably after the file chooser
> dialog
> > and after some memory intensive tasks). You should notice a lot of
> memory
> > being free'd up.
> >
> > -Alex
> >
> > On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote:
> > > Hi,
> > >
> > > I am porting a pygtk application to maemo. It works alright, but I
> > > noticed that it was consuming lot of memory, preventing me from
> opening
> > > other applications.
> > >
> > > When I investigated, I found that my python application was forking 4
> > > more instances of itself, each one identical in memory footprint. Thus
> > > they consumed nearly 60-70% of my memory.
> > >
> > > So I ran my application using pdb and narrowed down to a code segment
> > > that was leading to multiple instances of the process. It turned out
> > > that when I call run() on hildon.fileChooserDialog object, the dialog
> > > opens and at that moment in the "top" I see 4 more instances being
> > > forked.
> > >
> > > I fail to understand this behavior. I replaced the hildon widgets by
> > > pure gtk widgets and I see similar behavior, except that 2 more
> > > instances get forked. Also when using gtk.FileChooserDialog, these new
> > > instances get created in the instantiation of the dialog object,
> rather
> > > than call to run(). (code included below)
> > >
> > > So to further explore the problem, I ran same application on my
> desktop
> > > with gtk widgets. But I verified that when fileChooserDialog's run is
> > > called, there are no additional instances of python.
> > >
> > > I am running this code on n770, with 2007 HE and python2.5 runtime. My
> > > application code is pure python and not using any additional
> libraries.
> > > In fact following would be a simpler version of it to reproduce the
> > > problem:
> > >
> > > import gtk
> > > import hildon
> > >
> > > #window = gtk.Window(gtk.WINDOW_TOPLEVEL)
> > >
> > > #fileChooser = gtk.FileChooserDialog(
> > > #       title="Choose a photo to publish",
> > > #       buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,
> > > #       gtk.STOCK_OK, gtk.RESPONSE_OK))
> > >
> > > fileChooser = hildon.FileChooserDialog(
> > >         window,gtk.FILE_CHOOSER_ACTION_OPEN)
> > >
> > >
> > > result = fileChooser.run()
> > >
> > > if result == gtk.RESPONSE_OK:
> > >         print fileChooser.get_filename()
> > >
> > > Do you have any tips, as to what might be going wrong?
> > >
> > > This problem is fatal at least on n770 - it will trigger low memory
> > > message when other applications are used on the side.
> > >
> > > Any help will be useful.
> > >
> > > Thanks,
> >
> >
> > _______________________________________________
> > maemo-developers mailing list
> > maemo-developers at maemo.org
> > https://lists.maemo.org/mailman/listinfo/maemo-developers
> >
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>



-- 
---
Jayesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-developers/attachments/20071231/ce1eb494/attachment.htm