Hi Etienne On Fri, Jul 20, 2012 at 12:16 AM, Etienne Tourigny <[email protected]> wrote: > > I guess then the pragmatic way to resolve these kinds of issues is to > spawn them in working threads and implement mechanisms for cancelling > it. > Is this possible with the current api?
Well, there is generic Qt API - e.g. QtConcurrent or lower-level QThread to implement such mechanisms. > For example - could the browser dock run in a separate thread? That > way, if it becomes unresponsive at least the app isn't. At some point I would like to see this happen: when a user opens a folder, the browser dock would spawn a thread that gathers the layer information and once ready, it would signal that back to browser dock and the thread would be closed. As Juergen mentioned, such functionality is not for free: it is necessary to implement some locking mechanisms that would avoid race conditions (very ugly kind of bugs), and poorly implemented locking leads to dead locks. That's why it is a good idea to keep the amount of code that may be run in threads to a bare minimum. In any case, operations taking longer time should be done in threads and the event-driven approach is really a way how to move forward - I hope we will get such functionality in future. btw. The increasingly popular node.js (environment for server-side javascript) is completely based on the event-driven I/O. >> BTW the threading branch was/is addressing some of these issues. > > Are you referring to the inactive dev-threading branch? Any plans on > reviving that? I think there was a discussion about that a short while > ago. Yes, that's my GSoC project from some time ago... recently I've been trying to revive it (again!), at least the important bits. Let's see how that will end this time :-) Martin _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
