BackgroundWorker who knows how the magic works?

[Simon Tamman]

Just wondering if anyone knows how this component works.
If you set it up in the context of an Application.Run it works on it's
worker thread but it updates the progress on the UI thread.
My question is, how does it know which thread to use?

I used Reflector to track down the fact that it gets the delegates to call
via base.Events[SomeEventKey] which derives from Component but how does it
know what to put into base.Events?

I'm very happy the component is there as it's very useful for .NET 2.0
considering the changes to unhandled exceptions on threads. However i'd like
to know if it is possible to break it and how I could break it before I
start scattering instances of it throughout my projects.

Kind Regards

Simon Tamman

[Dave Sexton]

Hi Simon,

Just wondering if anyone knows how this component works.
If you set it up in the context of an Application.Run it works on it's
worker thread but it updates the progress on the UI thread.
My question is, how does it know which thread to use?

Basically, BackgroundWorker stores a reference to the current
SynchronizationContext when it begins the asynchronous process and uses the
reference after the process has completed to marshal the callback onto the UI
thread. (Check out the Send method)

"SynchronizationContext"
http://msdn2.microsoft.com/en-us/lib...xt(VS.80).aspx

Synchronization works with ASP.NET and WinForms through derived
SynchronizationContext implementations. The ASP.NET implementation is
internal, IIRC. The WinForms implementation is public:

"WindowsFormsSynchronizationContext"
http://msdn2.microsoft.com/en-us/lib...xt(VS.80).aspx

(You really don't need to be aware of the implementation to use the current
SynchronizationContext: SynchronizationContext.Current)

I used Reflector to track down the fact that it gets the delegates to call
via base.Events[SomeEventKey] which derives from Component but how does it
know what to put into base.Events?

EventHandlerList stores keyed delegates that are registered to handle specific
events. The key is proprietary. Usually, static System.Object instances are
used to key events in the list.

The purpose of an event handler list is to save memory when a component
exposes many events but when only a handful are used simultaneously. This
way, it is no longer necessary to make room for the memory required to store
the private delegate fields for every event.

I'm very happy the component is there as it's very useful for .NET 2.0
considering the changes to unhandled exceptions on threads. However i'd like
to know if it is possible to break it and how I could break it before I
start scattering instances of it throughout my projects.

Break what exactly?

--
Dave Sexton

[Simon Tamman]

Thank you very much for the information Dave.

SynchronizationContext.Current

is new to me and is valuable information.

In terms of breaking it:

If I marshalled a worker progress to a different UI thread, that'd kill it.
Not likely that i'd ever be in a position to do that but it's nice to know
the boundaries of anything automagic.

Thanks again!

Simon.

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:e4*************@TK2MSFTNGP02.phx.gbl...

Hi Simon,

Just wondering if anyone knows how this component works.
If you set it up in the context of an Application.Run it works on it's
worker thread but it updates the progress on the UI thread.
My question is, how does it know which thread to use?

Basically, BackgroundWorker stores a reference to the current
SynchronizationContext when it begins the asynchronous process and uses

the

reference after the process has completed to marshal the callback onto the

UI

thread. (Check out the Send method)

"SynchronizationContext"

http://msdn2.microsoft.com/en-us/lib...xt(VS.80).aspx

>
Synchronization works with ASP.NET and WinForms through derived
SynchronizationContext implementations. The ASP.NET implementation is
internal, IIRC. The WinForms implementation is public:

"WindowsFormsSynchronizationContext"

http://msdn2.microsoft.com/en-us/lib...xt(VS.80).aspx

>
(You really don't need to be aware of the implementation to use the

current

SynchronizationContext: SynchronizationContext.Current)

I used Reflector to track down the fact that it gets the delegates to

call

via base.Events[SomeEventKey] which derives from Component but how does

it

know what to put into base.Events?

EventHandlerList stores keyed delegates that are registered to handle

specific

events. The key is proprietary. Usually, static System.Object instances

are

used to key events in the list.

The purpose of an event handler list is to save memory when a component
exposes many events but when only a handful are used simultaneously. This
way, it is no longer necessary to make room for the memory required to

store

the private delegate fields for every event.

I'm very happy the component is there as it's very useful for .NET 2.0
considering the changes to unhandled exceptions on threads. However i'd

like

to know if it is possible to break it and how I could break it before I
start scattering instances of it throughout my projects.

Break what exactly?

--
Dave Sexton