Threading question; cross thread communication/invokation
-
I am working on a library that uses multiple threads to do all kinds of work. The work being done results in events being generated. Preferably I would like all communications to the outside world to be on a single thread, so most threading issues can be dealt with inside the library. When using forms there are the standard components with the
Invokemethods that let the thread that runs the form call the requestedDelegate, so whatever needs to be done (raise an event in my case) gets executed on that form thread. Is there a way to do this generically, withoutformsorcomponents? Say I have 1 main thread that spawns 10 or 20 worker threads. And whenever the workers have an event to raise, they let the main thread do this? Is there an easy way (that I just haven't found), or should I be creating some custom threadpool management code to achieve this? Any thoughts?If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
-
I am working on a library that uses multiple threads to do all kinds of work. The work being done results in events being generated. Preferably I would like all communications to the outside world to be on a single thread, so most threading issues can be dealt with inside the library. When using forms there are the standard components with the
Invokemethods that let the thread that runs the form call the requestedDelegate, so whatever needs to be done (raise an event in my case) gets executed on that form thread. Is there a way to do this generically, withoutformsorcomponents? Say I have 1 main thread that spawns 10 or 20 worker threads. And whenever the workers have an event to raise, they let the main thread do this? Is there an easy way (that I just haven't found), or should I be creating some custom threadpool management code to achieve this? Any thoughts?If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
the
BackgroundWorkerclass has this built-in: itsProgressChangedandRunWorkerCompletedhandlers run on the thread that created the BGW. :)Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
the
BackgroundWorkerclass has this built-in: itsProgressChangedandRunWorkerCompletedhandlers run on the thread that created the BGW. :)Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
Thx for your time. I get your point, but... that would make my library capable of only raising the standard
ProgressChangedandRunWorkerCompletedevents, and not the custom events used in my library. Is there any description on how the BackgroundWorker class does its magic? that would allow me to re-create it and add my own eventsIf you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
-
Thx for your time. I get your point, but... that would make my library capable of only raising the standard
ProgressChangedandRunWorkerCompletedevents, and not the custom events used in my library. Is there any description on how the BackgroundWorker class does its magic? that would allow me to re-create it and add my own eventsIf you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence
BGW's internals are pretty complex; it uses
System.ComponentModel.AsyncOperation,System.Threading.SynchronizationContextandSystem.Threading.ThreadPooland it basically boils down to aDelegate.InvokeYou can see all that with a tool such as Reflector[^]. :)Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
BGW's internals are pretty complex; it uses
System.ComponentModel.AsyncOperation,System.Threading.SynchronizationContextandSystem.Threading.ThreadPooland it basically boils down to aDelegate.InvokeYou can see all that with a tool such as Reflector[^]. :)Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
Meanwhile I ran some tests and my conclusion is that I cannot use the BackgroundWorker. Thing is with the
BackgroundWorker, that the described behaviour is only valid in a windows forms application. If you run it in a forms application, theProgressChangedhandler indeed runs on the creator thread (the UI thread), but if you use it in a console application, theProgressChangedhandler runs on theDoWorkbackground thread.If you want something done fast, then do it right (Grissom, CSI) Thanks for your reply, you just acknowledged my existence