Apache OpenOffice (AOO) Bugzilla – Issue 78414
Save dialog abuse threads
Last modified: 2017-05-20 11:31:32 UTC
Each time I type a character in the (Native) Save dialog, OOo kick on/off a thread as gdb outputs. [New Thread 1086355776 (LWP 12063)] [Thread 1086355776 (LWP 12063) exited] [New Thread 1086355776 (LWP 12064)] [Thread 1086355776 (LWP 12064) exited] [New Thread 1086355776 (LWP 12065)] [Thread 1086355776 (LWP 12065) exited] [New Thread 1086355776 (LWP 12066)] [Thread 1086355776 (LWP 12066) exited] [New Thread 1086355776 (LWP 12067)] [Thread 1086355776 (LWP 12067) exited] [New Thread 1086355776 (LWP 12068)] [Thread 1086355776 (LWP 12068) exited] [New Thread 1086355776 (LWP 12069)] [Thread 1086355776 (LWP 12069) exited] [New Thread 1086355776 (LWP 12070)] [Thread 1086355776 (LWP 12070) exited] [New Thread 1086355776 (LWP 12071)] [Thread 1086355776 (LWP 12071) exited] [New Thread 1086355776 (LWP 12072)] [Thread 1086355776 (LWP 12072) exited] [New Thread 1086355776 (LWP 12073)] [Thread 1086355776 (LWP 12073) exited] [New Thread 1088457024 (LWP 12074)] [Thread 1088457024 (LWP 12074) exited] [New Thread 1088457024 (LWP 12075)] I can understand to have a thread of asynchronous auto-completion but why creating/killing each time? It should be created when need, or when the dialog is open, and terminated upon exit.
pl->fs: I guess he's talking about our filepicker, not the native one. Could you please have a look ? Anyway this is not a patch issue as there is no patch, moreover it is a performance enhancement request, not a defect.
No I was talking about the native one.
Then this would seem to be a gtk problem ?
I think I got confused there. I mean the VCL file dialog, clearly not the Gtk file dialog. It is m211, ooo-build. (that's what I mean by native, and realize that by native you meant native to the platform, gtk in that case). In the Option -> General, I have Open/Save Dialogs [x] Use OpenOffice.org dialogs checked.
that's the SvtURLBox, isn't it?
This code was written a long time ago by a developer who has left years ago. At times we cleaned things up a bit or fixed bugs but usually we try not to touch it. What sense does it make to touch the code, invest development and testing time, have regression risks etc.? Is there a *real* problem except the fact that this is indeed ugly code?
The problem is that as of today, OpenOffice.org (Sun's) still ship with these dialogs by default instead of using the fpicker by default. So we can't really consider this code deprecated.
That wasn't my point. I wonder if the gain is worth the effort. That would be the case if the creation of many threads instead of one would cause a real problem under some circumstances. Currently I only see that we would fix some ugly code that currently just works. So why change it - just because it is ugly? That's the difference between "OOLater" and any other target. :-)
@hub: so is there anything that should convince me that "Later" isn't the right target? I still fail to see the "real" problem. Only making code "nicer" is not motivation enough to touch risky code.
Just to please the statistics I set the target to "OOoLater". As explained in my last comment I'm willing to change that if a real life case shows that this "inelegant" (ab)use of threads causes a problem for users.
Reset assigne to the default "issues@openoffice.apache.org".