Jon Sleet --mult- threading

[sasha]

Jon, it's be nice if you would update your Multi-threading in .NET
article using 3.5 features.

Thanks

 

[Jon Skeet [C# MVP]]

Jon, it's be nice if you would update your Multi-threading in .NET
article using 3.5 features.

I don't know of many new features in .NET 3.5 with respect to
threading, to be honest. There's plenty I'd like to do in terms of
BackgroundWorker, and I suppose the examples could use C# 3.0 features
such as lambda expressions, but what were you particularly thinking of
from .NET 3.5?

I don't know when I'll get round to it, to be honest - it would be nice
to do, but I'm pretty busy

 

[Bob]

I don't know of many new features in .NET 3.5 with respect to
threading, to be honest. There's plenty I'd like to do in terms of
BackgroundWorker, and I suppose the examples could use C# 3.0 features
such as lambda expressions, but what were you particularly thinking of
from .NET 3.5?

I don't know when I'll get round to it, to be honest - it would be nice
to do, but I'm pretty busy

I was just wondering if BackgroundWorker will be updated to provide
more graceful exit of the background thread. Any provision for
synchronizing the abort so the threaded process can organize file
closes, etc.?

 

[Marc Gravell]

I was just wondering if BackgroundWorker will be updated to provide

more graceful exit of the background thread. Any provision for
synchronizing the abort so the threaded process can organize file
closes, etc.?

I'm fairly certain nothing has changed in those areas. And even if it
had, it would most likely be ".NET 2.0 SP {x}", rather than .NET 3.5
itself. Re "synchronizing the abort" - I'm not entirely sure what you
mean, but you can subscribe to RunWorkerCompleted, which will fire (on
success, cancellation or failure, which you can determine from the
event-args) on the UI thread.

Marc

 

[Eric B.]

I'm fairly certain nothing has changed in those areas. And even if it
had, it would most likely be ".NET 2.0 SP {x}", rather than .NET 3.5
itself. Re "synchronizing the abort" - I'm not entirely sure what you
mean, but you can subscribe to RunWorkerCompleted, which will fire (on
success, cancellation or failure, which you can determine from the
event-args) on the UI thread.

Marc

From the MSDN Lib:

"You must be careful not to manipulate any user-interface objects in your
DoWork event handler. Instead, communicate to the user interface through the
ProgressChanged and RunWorkerCompleted events."

I found this out the hard way. If you do anything to the UI in the DoWork
you run the risk of causing problems. And it won't report any error either,
the BackgroundWorker will just abruptly and silently abort operation and
jump to the next piece of code leaving you to scratch your head.

Eric B.

 

[Marc Gravell]

"You must be careful not to manipulate any user-interface objects in

your DoWork event handler. Instead, communicate to the user interface
through the ProgressChanged and RunWorkerCompleted events."

Or through suitable use of Control.Invoke; but yes: ProgressChanged and
RunWorkerCompleted make life a lot easier.

Actually, in debug it *might* tell you about the problem (cross-thread
etc) - but only if you get lucky ;-p

And if it fails, it won't do it completely silently: it will raise
RunWorkerCompleted with an argument that contains an exception.

Marc

 

[Eric B.]

Or through suitable use of Control.Invoke; but yes: ProgressChanged and
RunWorkerCompleted make life a lot easier.

Actually, in debug it *might* tell you about the problem (cross-thread
etc) - but only if you get lucky ;-p

And if it fails, it won't do it completely silently: it will raise
RunWorkerCompleted with an argument that contains an exception.

Marc

In my experience it never jumped to RunWorkerCompleted, at least not while
stepping through the code in debug mode.

Eric B.