je**********@gmail.com wrote:
Is there a way to prevent one event from firing while another event is
already being fired?
No, not really. If you have complete control over the event, you could
add logic to the point in the code where the event is raised. But since
that's pretty obvious and since you're still asking the question, I'm
assuming you don't have complete control over the events (presumably
they are implemented in other classes you use but did not write).
I have a tool that extracts media from web pages and it has multiple
events firing when the status of the download changes.
Some of the events are used to tell the next file to download while
others manager other resources. However, on occasion, one event will
fire while the other is in the middle of a lock. Since the event hits
a locked resource, it cannot move and I get a deadlock.
Who caused the deadlock? Is your code the one that is using the locked
resources? If so, then you also need to design your architecture so
that you don't have one thread trying to get a resource another already
has while that other thread is trying to get the resource the first
thread already has.
If the code that caused the deadlock is outside your control, the author
of that code needs to fix it.
What I would really like to do is have the events queue up and run one
at a time. I am thinking my problem is my design decision in the
beginning to avoid an extra thread by using events to handle download
progress. However, I would like to know if queueing threads is even
possible.
I don't understand your comment that using events in some way avoids an
extra thread. Events and threads are orthogonal ideas; one does not
exclude the other, though it's true that if you want to prevent your
event handlers from deadlocking each other, one fix is to _not_ have
multiple threads.
How is it you believe that using an event has avoided a thread?
There are ways to ensure that execution of specific code is done in a
synchronous manner. The delegate type does in fact make this
potentially easier, since you can either create your own queue of
delegates with an object array for the parameters and process it
yourself, or take advantage of the Control.BeginInvoke() method to queue
execution of delegates on a very specific thread (the thread that owns
the control). But these methods aren't specific to events; you would
have to incorporate them into your own event handlers explicitly.
A better approach would be to understand why you are deadlocking and to
fix the design error in your code that led to that in the first place.
Pete
