BTW: It flashes ... after 5 secs.
Solution I: Setting WORKER_STAY_ALIVE_TIME to 1 sec.
That should be a compromise between thread pooling
and user feedback. (i really prefer 5 secs)
Solution II: We can do a test before we
send a worker thread to the idle/stay alive wait.
If it is the last surviver we can
trigger the Listeners. This would exactly
reproduce the behavior of the original ThreadQueue
(modulo the fact that there is really one semi-dead
thread remaining and not zero).
But I repeat myself: Jon falls into his own
trap here. He is assuming that no
more running threads is same as an empty
job queue. So there is no guarantee that the
flash will come at the right time.
(Yeah, I know it works in 95,731%!)
What is needed is a clean notification
solution when a rendering(zoom) is done.
But this is only possible with an enhanced
RenderingManager. (<- my goal)
- Sascha
Sascha L. Teichmann schrieb:
> Not if you want to do thread pooling.
>
> The real problem: How can I get a notification
> when a zoom is done?
>
> The ZoomToSelectedItemsPlugIn ThreadQueue code looks
> like a workaround due to lack of a real possibility
> to get informed when the zoom is done.
>
> I will have a look at this problem.
>
> regards,
> Sascha
>
>
> Larry Becker schrieb:
>> I cut the WORKER_STAY_ALIVE_TIME to 50 ms and the flash now works. 50
>> ms is an eternity in CPU time anyway.
>>
>> regards,
>> Larry
>>
>> On 6/15/07, Larry Becker <[EMAIL PROTECTED]> wrote:
>>> Thanks for finding that Listener use in ZoomToSelectedItemsPlugIn. I
>>> tried it and it doesn't flash anymore.
>>>
>>> regards,
>>> Larry
>>>
>>> On 6/15/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>>>> In core the
>>>>
>>>> com.vividsolutions.jump.workbench.ui.zoom.ZoomToSelectedItemsPlugIn
>>>>
>>>> uses the ThreadQueue.Listener interface. But the code looks like it can
>>>> cope with the 'slightly' shifted semantic.
>>>>
>>>> I would vote for stick a @deprecated tag (+ some explanations)
>>>> to the respective methods and to the interface because code
>>>> that uses these mechanisms is possibly not aware of the
>>>> sophisticated difference between 'no running threads left'
>>>> and 'all jobs done'.
>>>>
>>>> - Sascha
>>>>
>>>>
>>>> Larry Becker schrieb:
>>>>> Hi Sascha,
>>>>>
>>>>> Adding a 'wakeup' Runnable works great and is easier than using the
>>>>> listener anyway.
>>>>>
>>>>> By the way, I couldn't find any other code using the Listener
>>>>> interface, but I suppose there could be a Plug-in somewhere that does.
>>>>> We should probably leave it out anyway since if we are leaving it in
>>>>> for compatibility, it should actually be compatible. The easiest way
>>>>> to find out if it is really needed by anyone but me might be to leave
>>>>> it out and see if it breaks anyone's compile. The same applies to
>>>>> getRunningThreads since it doesn't behave exactly like it did before
>>>>> either.
>>>>>
>>>>> Anyway, thanks for the help. I'm able to determine the end of
>>>>> rendering much more accurately now.
>>>>>
>>>>> regards,
>>>>> Larry Becker
>>>>>
>>>>> On 6/15/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote:
>>>>>> Hello Larry,
>>>>>>
>>>>>> the version of the ThreadQueue is a bit outdated.
>>>>>> The version you have has no getRunningThreads() method.
>>>>>> This is need for compatibility. And there was a bug in
>>>>>> remove(Listener) which is fixed by now.
>>>>>> I attach the current ThreadQueue.
>>>>>>
>>>>>> Now to your problem:
>>>>>>
>>>>>> The Listeners are in for compatibility and you are right
>>>>>> they get there kick when the WORKER_STAY_ALIVE_TIME has
>>>>>> expired. But once again: These Listeners _do_ _not_ help
>>>>>> you! You want to know when the last job has ended, not
>>>>>> when there are no more running Threads. We discussed this
>>>>>> already.
>>>>>>
>>>>>> I would suggest the following solution on your side
>>>>>> to archive the desired effect:
>>>>>>
>>>>>> <code>
>>>>>>
>>>>>> Graphics2D destination = ... // from outer space
>>>>>>
>>>>>> LayerViewPanel layerViewPanel = ... // from outer space
>>>>>>
>>>>>> RenderingManager renderingManager =
>>>>>> layerViewPanel.getRenderingManager();
>>>>>>
>>>>>> ThreadQueue defaultThreadQueue =
>>>>>> renderingManager.getDefaultRendererThreadQueue();
>>>>>>
>>>>>> // add all the Renderer Runnables to the ThreadQueue
>>>>>> renderingManager.renderAll();
>>>>>>
>>>>>> final boolean [] locked = { true };
>>>>>>
>>>>>> // because defaultThreadQueue does its jobs
>>>>>> // one after each other append a 'wakeup' Runnable ...
>>>>>>
>>>>>> defaultThreadQueue.add(new Runnable() {
>>>>>> public void run() {
>>>>>> synchronized (locked) {
>>>>>> locked[0] = false;
>>>>>> locked.notify();
>>>>>> }
>>>>>> }
>>>>>> });
>>>>>>
>>>>>> try {
>>>>>> synchronized (locked) {
>>>>>> // you could simply write
>>>>>> // "while (locked[0]) locked.wait();"
>>>>>> // but following is more defensive
>>>>>> int count = 0;
>>>>>> while (locked[0] && count++ < 10)
>>>>>> locked.wait(10000L);
>>>>>> }
>>>>>> }
>>>>>> catch (InterruptedException ie) {
>>>>>> }
>>>>>>
>>>>>> renderingManager.copyTo(destination);
>>>>>>
>>>>>> </code>
>>>>>>
>>>>>> But as I said earlier, this only works on
>>>>>> the defaultRenderingThreadQueue and therefore
>>>>>> its only an interim solution. The
>>>>>> WMS/DB ThreadQueue is private and a true
>>>>>> parallel ThreadQueue.
>>>>>>
>>>>>> My goal is to add a renderAllSynchronized()
>>>>>> to RenderingManager that used the above
>>>>>> Runnable/unlock trick. The secret WMS/DB
>>>>>> will be eliminated (or better the default one
>>>>>> and the WMS/DB ThreadQueue will become the
>>>>>> default). This is doable with the
>>>>>> RunnableArrayList class I posted a while
>>>>>> ago, which simulates the single thread
>>>>>> default ThreadQueue. But one step after
>>>>>> the other ...
>>>>>>
>>>>>> Regards, Sascha
>>>>>>
>>>>>>
>>>>>> Larry Becker schrieb:
>>>>>>> Sascha,
>>>>>>>
>>>>>>> I have reached a point where I need some help with the new
>>>>>>> ThreadQueue implementation. I have modified my code that calls
>>>>>>> getRunningThreads to use the Listener with the
>>>>>>> allRunningThreadsFinished method instead. This was much cleaner and
>>>>>>> worked fine until I replaced ThreadQueue with your version. The
>>>>>>> problem I seem to be having is that the method doesn't fire until
>>>>>>> after the 5 second WORKER_STAY_ALIVE_TIME has expired. Can you
>>>>>>> explain what I should be doing or modify the code so that it fires
>>>>>>> when there are no more jobs waiting?
>>>>>>>
>>>>>>> I have attached the version of ThreadQueue.java that I have been using
>>>>>>> in case it is outdated.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Larry Becker
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> -------------------------------------------------------------------------
>>>>>>> This SF.net email is sponsored by DB2 Express
>>>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>>>> http://sourceforge.net/powerbar/db2/
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Jump-pilot-devel mailing list
>>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>> -------------------------------------------------------------------------
>>>>>> This SF.net email is sponsored by DB2 Express
>>>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>>>> control of your XML. No limits. Just data. Click to get it now.
>>>>>> http://sourceforge.net/powerbar/db2/
>>>>>> _______________________________________________
>>>>>> Jump-pilot-devel mailing list
>>>>>> Jump-pilot-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>>>
>>>>>>
>>>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by DB2 Express
>>>> Download DB2 Express C - the FREE version of DB2 express and take
>>>> control of your XML. No limits. Just data. Click to get it now.
>>>> http://sourceforge.net/powerbar/db2/
>>>> _______________________________________________
>>>> Jump-pilot-devel mailing list
>>>> Jump-pilot-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>>>
>>> --
>>> http://amusingprogrammer.blogspot.com/
>>>
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
