The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

.Net - Raise Event on thread of handler(s)

I am creating a utility class that I want to use in different types of projects (console, windows service and windows forms). The class uses it's own thread internally to do some work and periodically I want to raise progress events.

I have figured out how to do this in a Windows Forms project by passing the form into the class and using it's ComponentModel.ISynchronizeInvoke interface to invoke the event handler in the form's thread via a delegate.

Basically, by passing in the form, I'm passing in a "callback object"... However, this presents 2 problems that I can see:

1.) There are no forms in a Console project or a Windows Service project.

2.) (More importantly), if I have to pass a callback object into the class, it defeats the purpose of events based programming. I can't have multiple event listeners without a lot of work.

Does anyone else have a better way? Isn't there a way to say "hey, call all of this event's handlers in their own threads."?
Wayne B Send private email
Monday, November 07, 2005
 
 
Maybe I'm not understanding this correctly. I'm kind of new to multi-threaded programming.

According to comments in this MSDN chat, there is no way to do it:

http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_032304.aspx
Wayne B Send private email
Monday, November 07, 2005
 
 
I can't really see why you'd want to this... The handlers themselves can spawn processes on other threads.  I'd probably take that approach.
Jacob Send private email
Monday, November 07, 2005
 
 
Take a look at the new BackgroundWorker class in .NET 2.0. It does this. There are .NET 1.1 implementations as well. Just google for "BackgroundWorker".
Turtle Rustler
Monday, November 07, 2005
 
 
WHAT THE HELL????

I posted a frikn example of how to flip an event onto the UI thread, and my post is gone????

How could that have possibly looked like spam?
Chris Tavares Send private email
Tuesday, November 08, 2005
 
 
Chris, I see posts appearing, disappearing, and reappearing all the time. Something is seriously screwy about these boards, so I wouldn't worry about it. It will probably pop up again one of these days.
sloop
Tuesday, November 08, 2005
 
 
Well, I already know how to do it on the UI thread anyway.

I just want to build a component that raises events that other developers can use anywhere. I guess I will have to have 2 threads or a timer on the main thread that polls for events.

I have no examples of how to do this though. I have not been able to find a single one...
Wayne B Send private email
Tuesday, November 08, 2005
 
 
And the original post is back. Very strange.

As I said originally, I personally thing you need to use a "receiver makes it right" philosophy when it comes to multi-threaded events. The receiver knows what it needs to do to get the event onto the right thread, the sender cannot.

Just make sure that you document that the event may fire on a  background thread.

Or am I missing the question entirely?
Chris Tavares Send private email
Tuesday, November 08, 2005
 
 
Surely the fundamental issue here is that:
- marshaling an event to a UI thread works because a UI thread spends most of its time pumping messages, so can be interrupted naturally. 
- a worker thread or the main thread in a console application can't be naturally interrupted to process the event.  The only way is for the thread to poll.  This isn't particularly efficient in most cases which is one reason you won't find many examples.  But it's simple enough to do if that's really what you want.
Joe
Tuesday, November 08, 2005
 
 
Okay, so "receiver makes it right" philosophy it is then.

I'm just not used to having to think about this coming from VB6.

Thx all.
Wayne B Send private email
Tuesday, November 08, 2005
 
 
Did you look up the "BackgroundWorker" component on Google? There is a .NET 1.1 implementation out on:

http://weblogs.asp.net/rosherove/articles/BackgroundWorker.aspx

I don't know about the link above but the .NET 2.0 version works from Console Apps and Services as well as Windows Forms. If nothing else, you should use it as a model for how to do your own.
Turtle Rustler
Tuesday, November 08, 2005
 
 
Chris & sloop,

I don't trust any forum software or contact formular, anymore. Ctrl-A Ctrl-C (for the Win users) are your friends before clicking the submit-button, just in case...
Secure
Wednesday, November 09, 2005
 
 
I am checking out the background worker implentation right now.

Thanks.
Wayne B Send private email
Wednesday, November 09, 2005
 
 
I recommend creating your own message pump (e.g. by implementing ISynchronizeInvoke) for your worker threads.  That is a good way to implement the Active Object design pattern.  I agree that it is up to the receiver to marshall to his own thread.

Also, use asychronous messages between threads as much as possible.  Threads blocking on other threads (e.g. with locks, or by calling Invoke instead of BeginInvoke) often lead to deadlock.
Sean Forbes Send private email
Wednesday, November 09, 2005
 
 
How does a thread block another thread by calling Invoke? (on a delegate i presume you're talking about?)

How do you implement asynchronous messages between threads? The way I understand it is that if I call a delegate using BeginInvoke, it creates a whole new thread from a thread pool.
Wayne B Send private email
Thursday, November 10, 2005
 
 
When you call Invoke, it blocks the thread that you're in doesn't it?
Wayne B Send private email
Thursday, November 10, 2005
 
 
BeginInvoke is asynchronous.

Invoke is synchronous.
Chris Tavares Send private email
Thursday, November 10, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz