<br><br><div><span class="gmail_quote">On 12/31/07, <b class="gmail_sendername">Jayesh Salvi</b> <<a href="mailto:jayesh@altfrequency.com">jayesh@altfrequency.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'm not sure but think it is because of gnome-vfs. Don't know proper
<br>terminology but maybe each vfs 'provider' in the dialog (like mmc, phone
<br>etc.) starts new process or something like that.<br><br></blockquote></div></span>That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes.
<br><br>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.
</blockquote><div><br>I guess there isn't much to do - for an app programmer at least. I found the same behavior with osso_pdfviewer. It also uses hildon's FileChooserDialog. But even before that dialog is invoked, multiple processes are forked. ... and they do not disappear until their parent exits. They keep occupying the same amount of memory as their parent. This is really taxing on my n770.
<br><br>If this is the default behavior of gnome-vfs based GTK apps, then I hope it gets improved for embedded devices.<br><br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-- <br>---<br><span class="sg">Jayesh
</span></blockquote></div><br><br clear="all"><br>-- <br>---<br>Jayesh