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
