Jon Sleet --mult- threading

  • Thread starter Thread starter sasha
  • Start date Start date
S

sasha

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

Thanks
 
sasha said:
Jon, it's be nice if you would update your Multi-threading in .NET
article using 3.5 features.
Click to expand...

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 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 :(
Click to expand...

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 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.?
Click to expand...

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
 
Marc Gravell said:
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
Click to expand...

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.
 
"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."
Click to expand...

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
 
Marc Gravell said:
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
Click to expand...


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

Eric B.
 
Back
Top