You bring up a very good point here.
Current State of affairs:
Each map has a thread with which the commands sent to that map can be
ran. So commands can be ran in parallel provided they are sent to
different maps. However, operations (of a single type) have a single
thread that runs all requests. I think I agree with you that this is
not optimal. Most likely there should be a thread pool that is used
to run the operations, as you know too many threads can be worse than
not enough threads.
My proposed plan for operations is there can be a pool of threads
that all operation requests can use. That means multiple operations
of the same type could be executed in parallel. If you like this
idea would you please make a bug report?
Jesse
On 9-May-06, at 3:54 AM, Jonas Johansson wrote:
Hi,
We had the below discussion about threads more than a month ago,
here is
a follow-up since I just discovered something unexpected today.
I had the impression that operations of a map runs in parallel in
separate threads, including operations of the same type. This appears
not to be the case.
Case 1:
Launch a time-consuming "command1" in parallel with another almost
instantly returning "command2".
Result: The commands execute in parallel on the server -> command2
returns while command1 is still running.
Case 2:
Launch the time-consuming "command1" in parallel with another
time-consuming "command1" (notice, same type).
Result: Serial execution on the server (The second command does not
seem
to reach the server before the first command is finished).
So my guess is that uDig is serialising operations of the same
type. If
I'm wrong I guess I am screwing something up at the server, but I
don't
think so, since different operation types runs fine.... If I'm right,
how come different operation types are allowed to run in parallel, but
not operations of the same type?
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
