Thanks Jesse, Yes, I don't really see why not go all the way. Both with local and remote operations, it is not hard to think of cases where the user might want to send off a series of time-consuming operations.
An operations thread pool sounds like exactly the thing that is needed. Jonas On Tue, 2006-05-09 at 09:57 -0700, Jesse Eichar wrote: > 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 _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
