Hi,

ext Jayesh Salvi wrote:
>> I'm not sure but think it is because of gnome-vfs. Don't know proper
>> terminology but maybe each vfs 'provider' in the dialog (like mmc, phone
>> etc.) starts new process or something like that.
>>
>> That sounds correct. I experimented with other dialogs that do no involve
> filesystem access (NamePasswordDialog, SortDialog), and they do not fork any
> extra processes.

They are not processes, but gnome-vfs worker threads
(you don't want the UI to freeze e.g. until network timeouts).


> So this behavior seems valid for FileChooserDialog. But then I should be
> able to cleanup those extra processes when I am done with the
> FileChooserDialog. I called destroy() on the dialog object, but that doesn't
> help.

They remain in the gnome-vfs thread pool even after the UI component
is destroyed.

The memory usage issue is elsewhere.  You could look into your
program Private_Dirty memory usage in /proc/PID/smaps file.
Or run the same program on your PC under Valgrind Massif plugin:
        http://maemo.org/development/tools/doc/valgrind
        http://valgrind.org/docs/manual/ms-manual.html

I'm not sure how well that tells about issues in Python code.
Is there any memory profiler for Python applications?


        - Eero
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers

Reply via email to