Problems with static events? (Or is there another way?)

[Colin Cashman]

In a program I'm writing, I have a class that generates a certain
event. However, there may be dozens or even hundreds of instances
of this particular class, which makes adding and removing handlers
to each instance a pain. Rather than go down that route, I was
thinking of making the event static, so I would only need to add my
handlers once, to the static event, which I can then trigger from
inside my class.

That leaves me with two questions:

1. Is there a better way to handle this than using static events?

(I thought of having another class own a "master" event, but that
simply introduces more connecting code, and is a bit messier when
it comes to encapsulation.)

2. If this IS the best way, are there any "gotchas" or problems
I should be aware of when using static events?
Thanks in advance!

Colin

[Justin Rogers]

You have quite a few options, with a static event probably being the
best option. Having static firing code is probably also a good action
to take, since it serializes your eventing code.

The only "gotcha" you are going to run into is that you can only have
a single *collection* of your class. Since you are using a static, if
any of your classes fires the event, then whomever is listening will
hear it. This means you can't provide any form of partitioning. An
example might be:

Say you have 10 people on a stock trading floor. All 10 people
initially listen to everything to figure out what they are interested in.
As time progresses, they eventually realize they only need to listen
to a portion of the floor that contains information they are interested
in. This would be identical to 10 event consumers that eventually
only want to listen to a subset of events.

Now, if you don't need the above partioning and can guarantee you'll
never need it, then move forward. If you do need partitioning then
start thinking back to that controller object you were thinking about.
At that level you can have a ClassSet that contains all instances of your
classes, and the ClassSet can be coerced into giving up ClassSubSet's
that only contain specific instances. A ClassSet might have a certain
frequency that it allows broadcasts on, say 1 every second, while the
ClassSubSet could allow more frequent broadcasting since the theoretical
number of consumers would be less.

Loads of options, and a very interesting problem. Keep us aprised for what
you are doing.
--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers
"Colin Cashman" <cd*@gis.net> wrote in message
news:Jrwxc.22778$Sw.16502@attbi_s51...

In a program I'm writing, I have a class that generates a certain
event. However, there may be dozens or even hundreds of instances
of this particular class, which makes adding and removing handlers
to each instance a pain. Rather than go down that route, I was
thinking of making the event static, so I would only need to add my
handlers once, to the static event, which I can then trigger from
inside my class.

That leaves me with two questions:

1. Is there a better way to handle this than using static events?

(I thought of having another class own a "master" event, but that
simply introduces more connecting code, and is a bit messier when
it comes to encapsulation.)

2. If this IS the best way, are there any "gotchas" or problems
I should be aware of when using static events?
Thanks in advance!

Colin

[John Baro]

I cannot see from what you have described what the "pain" is in adding and
removing handlers.
When you instantiate your class, you add the handler (using a common handler
for which accepts a "sender" parameter to provide information about which
instance fired the event).
When your class goes out of scope or you destroy it, the handler is removed.

I wouldnt think that using static events would be the way to go.

You might need to provide more info on your project to get the "right"
answer :)
HTH
JB

"Colin Cashman" <cd*@gis.net> wrote in message
news:Jrwxc.22778$Sw.16502@attbi_s51...

In a program I'm writing, I have a class that generates a certain
event. However, there may be dozens or even hundreds of instances
of this particular class, which makes adding and removing handlers
to each instance a pain. Rather than go down that route, I was
thinking of making the event static, so I would only need to add my
handlers once, to the static event, which I can then trigger from
inside my class.

That leaves me with two questions:

1. Is there a better way to handle this than using static events?

(I thought of having another class own a "master" event, but that
simply introduces more connecting code, and is a bit messier when
it comes to encapsulation.)

2. If this IS the best way, are there any "gotchas" or problems
I should be aware of when using static events?
Thanks in advance!

Colin

[Jon Skeet [C# MVP]]

Justin Rogers <Ju****@games4dotnet.com> wrote:

You have quite a few options, with a static event probably being the
best option. Having static firing code is probably also a good action
to take, since it serializes your eventing code.

What makes you say that? If two events fire from two different threads,
they will execute concurrently. Being static has no magic serialisation
powers here.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Anders Borum]

Hello!

I have been thinking about the same approach as Colin. I have a few extra
questions, which I hope you can answer.

For instance, what happens if you have a large number of instances that are
subscribing to an event? Imagine a hierarchical structure with e.g. 25.000
nodes that were subscribed to a change event. I haven't seen any examples
(patterns) or documentation that tries to give a good answer to that
problem.

Is 25.000 listeners simply too much (hence looking at another approach to
notifying the instances is worth considering)?

If you have any pointers in this direction, I would really appreciate them.

When your class goes out of scope or you destroy it, the handler is

removed.

If you're exposing the eventlistener as a public member, how do you keep
from getting dangling references (that is, instances that have gone out of
scope but haven't been gc'et because of the strong reference to the
eventlistener)?

--
venlig hilsen / with regards
anders borum
--

[cody]

> > You have quite a few options, with a static event probably being the

best option. Having static firing code is probably also a good action
to take, since it serializes your eventing code.
What makes you say that? If two events fire from two different threads,
they will execute concurrently.

When a static lock is placed in the method which lauches the event, no two
event can be lauched concurrently.
Being static has no magic serialisation
powers here.

I also didn't understand what was meant with serializing event code here.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[cody]

> I have been thinking about the same approach as Colin. I have a few extra

questions, which I hope you can answer.

For instance, what happens if you have a large number of instances that are subscribing to an event? Imagine a hierarchical structure with e.g. 25.000
nodes that were subscribed to a change event. I haven't seen any examples
(patterns) or documentation that tries to give a good answer to that
problem.

Is 25.000 listeners simply too much (hence looking at another approach to
notifying the instances is worth considering)?

If you have any pointers in this direction, I would really appreciate them.

When your class goes out of scope or you destroy it, the handler is removed.

The real question is: Do you really need events for this? Since the nodes
should already have an reference of its parent,
why not simply call a method on each node from the parent control to
simulate an event.
If you're exposing the eventlistener as a public member, how do you keep
from getting dangling references (that is, instances that have gone out of
scope but haven't been gc'et because of the strong reference to the
eventlistener)?

Forgetting to unsubscribe events before going out of scope is indeed a
problem for .NET. In the case of a parent control with nodes you can ensure
that NodeCollection.Add adds the handler and NodeCollection.Remove which
removed an item also unsubscribes the event.

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk

[Jon Skeet [C# MVP]]

cody <no****************@gmx.net> wrote:

You have quite a few options, with a static event probably being the
best option. Having static firing code is probably also a good action
to take, since it serializes your eventing code.

What makes you say that? If two events fire from two different threads,
they will execute concurrently.

When a static lock is placed in the method which lauches the event, no two
event can be lauched concurrently.

Sure - but that could be done whether or not the event is static.

Being static has no magic serialisation
powers here.

I also didn't understand what was meant with serializing event code here.

Indeed.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Colin Cashman]

> I cannot see from what you have described what the "pain" is in adding and

removing handlers.
The "pain" is that it goes against the structure of the code. The code
goes something like:

Class A (a singleton) contains class B, which in turn contains a
collection of hundreds or thousands of event generators (class C).
Elsewhere in the application, there are numerous other objects (D, E,
and F) that are interested in knowing when a particular change occurs in
the instances of class C. The class B is private to class A, and the
collections class instance (that contain the instances of C) is private
to class B.

So the "pain" is having to provide various pass-throughs in classes A
and B in order for classes D, E, and F to obtain the collection of event
generators so that they can attach their handlers.
When your class goes out of scope or you destroy it, the handler is removed.

My understanding is that having a handler attached to an instance makes
it harder for the GC to reclaim that instance (or, at least, makes
reclaiming the memory take longer).