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]]

Re: Jon Sleet --mult- threading

sasha <aborovinsky@gm ail.comwrote:

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
BackgroundWorke r, 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 :(

--
Jon Skeet - <skeet@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Bob]

Re: Jon Sleet --mult- threading

On Sun, 2 Nov 2008 22:43:52 -0000, Jon Skeet [C# MVP]
<skeet@pobox.co mwrote:

>sasha <aborovinsky@gm ail.comwrote:

>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
>BackgroundWork er, 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 BackgroundWorke r 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]

Re: Jon Sleet --mult- threading

I was just wondering if BackgroundWorke r 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 "synchroniz ing the abort" - I'm not entirely sure what you
mean, but you can subscribe to RunWorkerComple ted, which will fire (on
success, cancellation or failure, which you can determine from the
event-args) on the UI thread.

Marc

[Eric B.]

Re: Jon Sleet --mult- threading

"Marc Gravell" <marc.gravell@g mail.comwrote in message
news:16d792e3-f3bf-4e03-96d6-44606eb995a8@v2 2g2000pro.googl egroups.com...

>I was just wondering if BackgroundWorke r will be updated to provide
>more graceful exit of the background thread. Any provision for
>synchronizin g 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 "synchroniz ing the abort" - I'm not entirely sure what you
mean, but you can subscribe to RunWorkerComple ted, 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 RunWorkerComple ted 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 BackgroundWorke r 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]

Re: Jon Sleet --mult- threading

"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 RunWorkerComple ted events."

Or through suitable use of Control.Invoke; but yes: ProgressChanged and
RunWorkerComple ted 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
RunWorkerComple ted with an argument that contains an exception.

Marc

[Eric B.]

Re: Jon Sleet --mult- threading

"Marc Gravell" <marc.gravell@g mail.comwrote in message
news:eClNvsbPJH A.5080@TK2MSFTN GP03.phx.gbl...

>"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 RunWorkerComple ted events."

>
Or through suitable use of Control.Invoke; but yes: ProgressChanged and
RunWorkerComple ted 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
RunWorkerComple ted with an argument that contains an exception.
>
Marc

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

Eric B.