[prev in list] [next in list] [prev in thread] [next in thread] 

List:       velocity-dev
Subject:    Re: [SURVEY] IntrospectorCache(Listener)
From:       "Will Glass-Husain" <wglasshusain () gmail ! com>
Date:       2008-07-30 0:13:16
Message-ID: 2f8a5bd60807291713u4b545d9eo790192487b885640 () mail ! gmail ! com
[Download RAW message or body]

Nathan,

That seems fine to me.  If they are slowing down performance, let's
put the onus on the user/contributor to improve them.  (It's not clear
that the feature actually has users).

WILL

On Tue, Jul 29, 2008 at 4:47 PM, Adrian Tarau
<adrian.tarau@intellisoftsystems.com> wrote:
> Actually I forgot something : addListener and removeListener needs to be
> synchronized(we don't want to loose a change), but not  fireEvent(we just
> use the current array).
>
> Nathan Bubna wrote:
>>
>> On Tue, Jul 29, 2008 at 12:36 PM, Adrian Tarau
>> <adrian.tarau@intellisoftsystems.com> wrote:
>>
>>>
>>> The best way to implement listeners (as you may see in EventListenerList)
>>> is
>>> to work with arrays.They are immutable and have the lowest memory
>>> footprint(instead of HashSet/ArrayList or any concurrent class).
>>>
>>> Eventually you can skip copying the listeners array if you manage
>>> everything
>>> locally instead of having a class like EventListnerList(need it - maybe -
>>> if
>>> you fire events at a really high rate, so you want to avoid creating an
>>> array every time). If you encapsulate array changes in a class
>>> ArrayUtilities you will not add to much code to implement add/remove/fire
>>> listeners.
>>>
>>> public class A {
>>>
>>> Listener[] listeners =  new Listener[0] ;
>>>
>>> // add a new listener
>>> public void addListener(Listener listener) {
>>>  listeners = ArrayUtilities.addObject(listeners, listener);
>>> }
>>>
>>> // remove a listener
>>> public void removeListener(Listener listener) {
>>>  listeners = ArrayUtilities.removeObject(listeners, listener);
>>> }
>>>
>>> // fire event
>>> public void fireCodeChanged(Event event) {
>>>  Listener[] currentListeners =  this.listeners;
>>>  foreach(Listener listener : listeners) {
>>>      listener.onChange(event);
>>>  }
>>> }
>>>
>>
>> that's a good tip to know!  i'll remember that for other listener
>> implementations.
>>
>>
>>>
>>> Right now IntrospectorCacheImpl can fail with
>>> ConcurrentModificationExceptions if you don't add synchronized to
>>> addListener and removeListener.
>>>
>>
>> yeah, i immediately saw that too, and fixed it this morning, but then
>> decided that due to the utter lack of IntrospectorCacheListeners
>> responding to my little survey was justification for just ripping the
>> whole thing out.  So i did, and it is gone.  If anyone really wants to
>> watch the introspector cache, then let me know and i'll help make it
>> easy to plug in your own IntrospectorCache implementation that does
>> just that.  or, of course, if Henning feels it's important, he can
>> veto my changes, and i'll revert and find another way to boost
>> performance here. :)
>>
>>
>>>
>>> ....
>>>
>>> Nathan Bubna wrote:
>>>
>>>>
>>>> Given the lack of affirmative response, i'm going to take some wild
>>>> guesses here...
>>>>
>>>> On Thu, Jul 24, 2008 at 10:34 PM, Nathan Bubna <nbubna@gmail.com> wrote:
>>>>
>>>>
>>>>>
>>>>> 1) Does anyone out there actually use custom implementations of the
>>>>> IntrospectorCache interface?
>>>>>
>>>>>
>>>>
>>>> nope.
>>>>
>>>>
>>>>
>>>>>
>>>>> 2) Does anyone use any IntrospectorCacheListeners?
>>>>>
>>>>>
>>>>
>>>> no.
>>>>
>>>>
>>>>
>>>>>
>>>>> 3) Can anyone give me a use-case for IntrospectorCacheListeners?
>>>>>  (Henning?)
>>>>>
>>>>>
>>>>
>>>> yes, Henning, who is busy with other things.  Henning, if you would
>>>> like these back, i'll replace them then.  for now, i'm yanking them.
>>>> :)
>>>>
>>>>
>>>>
>>>>>
>>>>> For those curious about my reasons for asking:  i'm looking at
>>>>> IntrospectorBase and the classes above and seeing slight risk of
>>>>> ConcurrentModificationExceptions in the way listeners are handled.
>>>>> This would be trivially fixed by synchronizing the add/removeListener
>>>>> methods.  However, i'm hoping to use more fine-grained synchronization
>>>>> in those classes that would require potentially more hassle than the
>>>>> risk.  Loads of fun, ya know.  So, if i find out the listeners are
>>>>> used w/o problems, i won't worry about it.  If i find out they're not
>>>>> used at all and can't figure out what they're good for, then i would
>>>>> happily be rid of them. :)
>>>>>
>>>>> all input is welcome!
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>>>> For additional commands, e-mail: user-help@velocity.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: dev-help@velocity.apache.org
>>
>>
>
>



-- 
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]