Salut,
gustav trede wrote:
>
>
> 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.
Thanks!
>
>
>
> 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.
But this is not the default right now so we still need to improve the
current implementation IMO (and your proposal makes a right step).
What about a base class that implement CometHandler?
A+
-- jeanfrancois
>
>
>
>
> 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
> <mailto:dev-unsubscribe_at_grizzly.dev.java.net>
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> <mailto: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.
>