This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 16328

Summary: Make module system change firing synchronous
Product: platform Reporter: Jesse Glick <jglick>
Component: Module SystemAssignee: Jesse Glick <jglick>
Status: VERIFIED FIXED    
Severity: blocker CC: jtulach
Priority: P4    
Version: 3.x   
Hardware: PC   
OS: Linux   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 13352, 16329    
Bug Blocks: 15477, 26064    

Description Jesse Glick 2001-10-08 11:36:31 UTC 
During module reload, all of which happens inside the write mutex, PROP_ENABLED
is fired first to false then to true (when the mutex is exited). This is not
quite correct since when the mutex is entered and exited, this property has the
same value, so technically no change should be fired. Generally ChangeFirer
should account for the situation where more than one change within a given write
mutex is posted for the same source and property: only one change should be
fired; its old value should be taken from the first posted one; its new from the
last; and if it is the case that for any pair of adjacent changes posted, the
old and new values are both non-null and different, this is an illegal state;
and if the old and new values of the single change would thus be non-null and
equal, no change at all should be fired.

Also Yarda says that ChangeFirer should not need to be a separate thread, you
can post a read mutex request and it will run immediately after the write mutex
is exited, which would be more predictable.
Comment 1 Jesse Glick 2001-11-06 11:34:08 UTC 
I am not sure if this is actually a valuable goal.... it seems many
more people are relying on module change firing than was a design goal
for it (it was intended as a very marginal feature for obscure display
purposes, perhaps). Perhaps it should be synchronous, with the write
mutex held but only read operations permitted. This would simplify a
lot of code and tests too. Basically, there would be a global "firing"
flag; mutating methods would first check that it was off, and that the
method is inside a write mutex, then do their thing, then turn it on,
fire changes, then turn it off. This would make the synchronization
very safe and the timing more predictable. What do you think? (Depends
on a feature in mutex...) Not for 3.3 but for later.
Comment 2 Jaroslav Tulach 2001-11-06 14:19:50 UTC 
The requested change in mutex has been implemented, I guess. Otherwise
I managed to solve the firing issue, I do not need it anymore.
Comment 3 Jesse Glick 2001-11-06 14:58:36 UTC 
#13352 is what I was referring to.
Comment 4 Marek Grummich 2002-07-22 08:33:23 UTC 
Target milestone was changed from '3.4' to TBD.
Comment 5 Marek Grummich 2002-07-22 08:44:34 UTC 
Target milestone was changed from '3.4' to TBD.
Comment 6 Marek Grummich 2002-07-22 08:44:58 UTC 
Target milestone was changed from '3.4' to TBD.
Comment 7 Marek Grummich 2002-07-22 08:49:32 UTC 
Target milestone was changed from '3.4' to TBD.
Comment 8 Jesse Glick 2002-08-24 05:36:22 UTC 
I have a patch which causes all module system changes to be fired
synchronously at the end of the mutator method. Though you are inside
a write mutex, you are prevented from making any mutations within the
scope of the change callbacks. This is very simple and predictable as
threading things go, and should be intuitive for users of the
JavaBeans spec which requires something very similar.
Comment 9 Jesse Glick 2002-08-24 06:46:47 UTC 
ChangeFirer.java 1.5
Module.java 1.32
ModuleManager.java 1.39

Note that ModuleManagerTest still uses a timeout-based PCL when
testing whether changes are fired. In fact the timeout could probably
now be deleted if desired.
Comment 10 Marian Mirilovic 2005-07-13 13:20:15 UTC 
closed