>
> people who use the current interface will get the current isactive code
>> path, that scales bad.
>>
>
> Any numbers to prove that :-) I know it is not the best implementation :-)
not yet, but a volatile access compared to concurrentlinkedlist that grows
with the number of handlers.
its a low fixed cost compared to a base cost that is several times and then
scales to even more expensive with the number of comethandlers.
>
> and slow clients can more easily stop alot of
>
>> threads with IO.
>>
>> If using executors along with the old interface we have 2 options to
>> ensure basic threadsafety,
>> users remember to synchronize their onEvent method (this is how its done
>> today ! )
>> i decided to add a lock for notify0 onEvent call in
>> Defaultnotificationhandler when the old interface is detected
>>
>
> Make sense. So with that, the onEvent no longer needs to be synchronized?
true, no need for it.
>
>
> A+
>
> -- jeanfrancois
>
>
>
>>
>> whats your opinion ?
>>
>>
>> --
>> your servant
>> gustav trede
>>
>> coding is art - not only something that bring food on the table,
>> everybody should be able to feel proud about their code,
>> that they have performed their best considering the given conditions.
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
--
your servant
gustav trede
coding is art - not only something that bring food on the table,
everybody should be able to feel proud about their code,
that they have performed their best considering the given conditions.