I think you've got it.
Jesse
On 30-Mar-06, at 10:02 AM, Jonas Johansson wrote:
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
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
