Thanks very much Jesse, that was good to know! I will experiment some with this. It might be the case, then, that it is actually be better *not* to do the WPS I/O as a Command since it would be serialised against other commands. I should however add the resulting new layer as a command since that modifies the data model.
Jonas On Thu, 2006-03-30 at 08:15 -0800, Jesse Eichar wrote: > HI Jonas, > > Each map has a thread in which it executes its commands. Commands > must be executed serially in order for them to have meaning when > undone. So that is a single thread. Each operation has its own > thread so multiple operations can be run in parallel. And finally > the PlatformGIS has a run method which has a single thread in which > all the requests are ran. > > The sendCommandASync doesn't mean the command will run asynchronously > from all other commands, it means that the current thread will not > block while the thread runs. I will document this. It is similar to > the Display#asyncExec() and Dislay#syncExec(). > > Hope this helps clear things up. > > Jesse > > On 29-Mar-06, at 6:46 PM, Jonas Johansson wrote: > > > Hi all, > > > > While experimenting some to learn how uDig handles parallel > > execution of > > commands, I found an interesting thing. > > > > I use the Edit-tool to select an EditFeature in the Map view, and then > > execute the plug-in operation 'Buffer' which creates a command that > > only > > does the following: > > for(int i=0; i<99999999;i++) > > for(int j=0; j<100; j++); > > > > I send away the command asynchronically with > > ApplicationGIS.getActiveMap().sendCommandASync(command); > > > > and the operation completes (while the command is still spinning...). > > It appears that I can use other operations (such as Layer Summary) > > just > > fine in parallel with the command execution. So far so good. > > However, if > > I try to use the Edit-tool to select a new EditFeature, I have to wait > > for the asynchronous command to finish before the Edit-tool reacts on > > the mouse-click. So it appears the asynchronous command is not so > > asynchronous after all. Is this the way it should be? > > > > Can someone please explain if it is possible to do the above > > example in > > parallel, not having to wait for the previous command to finish until > > the next feature can be selected and send away another buffer > > command? I > > would like to be able to send away lots of buffer commands, and for > > each > > selecting a new feature, in parallel before the first one completes. > > > > Jonas > > > > _______________________________________________ > > User-friendly Desktop Internet GIS (uDig) > > http://udig.refractions.net > > http://lists.refractions.net/mailman/listinfo/udig-devel > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
