SS,
I think you've found the issue; thanks for the explanation. I wouldn't
worry about calling a listener with the event after it has been
de-registered because the event handlers are not guaranteed to be
executed in any given order.
In a perfect world (and the way most of us think about event handlers)
all the handlers for a given event are executed in tandem. Thus we could
create N threads (one per handler), leaving them all in a yielded state
prior to starting the execution of any one thread. This would also be a
valid implementation. If there are handlers which are order dependant
(and there shouldn't be any), they probably should be refactored.
HTH
David
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Sunburned Surveyor
Sent: January 18, 2007 7:52 AM
To: List for discussion of JPP development and use.
Subject: [JPP-Devel] Update on Bug #1487099
I'm afraid I have to again correct my observations on Bug #1487099. I
was looking at the LayerManager class this morning and realized that the
method causing Pedro's ConcurrentModificationException hasn't yet been
fixed by creating a copy of the LayerListener collection. This fix was
applied by Jon Aquino to some other methods.
After chewing over the problem for a while last night I realize that
creating a copy of the LayerListener collection stored by the
LayerManager class isn't a totally "thread safe" solution to this
problem. It does eliminate the possibility of the
ConcurrentModificationExceptions but I think it would allow a
LayerListener to be sent an event when it should not receive them.
Let me give a quick example of this scenario.
I did a little work on a Data Source Catalog that allows the user to
associate Layers and DataSources. As part of this extension for OpenJUMP
I might have created a LayerListener that presents a dialog box to the
user when a layer is deleted, or removed from the LayerManager. This
dialog box would ask the user if they would also like to delete any
DataSources associated with the Layer. Similarly, the LayerListener
might present a dialog box when a Layer is added to the LayerManager
asking the user if they would like to associate the new Layer with a
DataSource.
These 2 dialog boxes could get a little irritating, so I might include
an option that allows the user to turn it "off". This could easily be
done by removing the LayerListener from the LayerManager. This might
also be done programatically by other plug-ins that add or remove layers
as part of their operation.
Here is the problem.
The user performs some action that will cause a Layer to be added or
removed from the LayerManager. When this happens the LayerManager
creates a copy of the LayerListeners collection and begins to iterate
over it calling the appropriate methods of the LayerListeners in a new
thread.
The user then performs another action while this thread is running that
causes one of the LayerListeners to be removed from the LayerManager's
collection of LayerListeners. This LayerListener has not been removed
from the copy of the LayerListener collection that is being manipulated
by the thread created previously when a Layer was added or removed. That
means the LayerManager will pass the LayerChanged event to a
LayerListener that is no longer supposed to receive this event because
it is present in the copied collection. (It is no longer present in the
original LayerListener collection.)
I know this would be a rare occurence, but it is possible. I think it
leaves the potential for some hard-to-locate bugs in the future. I
believe this problem can be solved in a thread safe way by restricting
access the the LayerListeners collection with synchronized methods.
Like I said, I'm no expert at threads, and If I'm not understanding this
correctly I'd really appreciate some help!
If my theory about this situation isn't all messed up I'll get started
on the "thread safe" solution for the next release of OpenJUMP. I'll
work with Vivid Solutions to get it incorporated into JUMP as well.
Thanks for any input on this situation.
The Sunburned Surveyor
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
