.NET 3.5 Brings BREAKING Changes to ThreadPool

Why not join our community?, there are 7 users online

home
clr
view story

DotNetKick.com is an open-source project. Please report any bugs and let us know your great suggestions. Currently running svn revision 620 (rss)

Kick Spy!, Kick Zeitgeist and Kick Widgets

15
kicks

kick it

.NET 3.5 Brings BREAKING Changes to ThreadPool

published 4 months, 7 days ago, submitted by mkennedy66996693 4 months, 9 days ago

michaelckennedy.net — Things get more interesting with the .NET 2.0 SP1 ThreadPool.

8 comments | category:

CLR | Views: 3 | Get KickIt image code

tags: ThreadPool, .net3.5, CLR | tag it

Everyones tags:

Your tags:

Please login or signup.

Add a live kick counter to your blog >> liveImage

You can even customize the image by choosing your own colors, and then clicking the button below to update the preview and the html code:

"Kick It" text
"Kick It" background
kick count text
kick count background
border

Simply copy and paste this HTML into your blog post.

Users who kicked this story:

mkennedy66996693 -

atifaziz -

yesthatmcgurk - Reman - Vort3X - Lck84 -

JudahGabriel -

w3stfa11 - Loonquawl - ashmind - ChadMoran - happer - AdeBt - blacksauron - JonnyRocks

Comments:

Of course, these changes aren't BREAKING, but its interesting anyhow.

posted by

yesthatmcgurk 4 months, 8 days ago

Hi yesthatmcgurk. I think that they are breaking. This documents what amounts to a bug in the thread pool. Methods that used to have an effect no longer do. So if you rely on that behavior (of SetMinThreads) then your code breaks. Most people don't so to them it might not matter so much.

posted by mkennedy66996693 4 months, 8 days ago

[comment removed]

posted by Ralph 4 months, 6 days ago

I'll need to use that one next time I get a bug report - "Hey, what do you want from me? The code compiled!".

posted by confuzatron 4 months, 6 days ago

Beg pardon. Just checked Ralph's comment history and he's apparently a trolling asshole.

posted by confuzatron 4 months, 6 days ago

Nice article, thanks for sharing.
IMHO this is a very important modification in the behaviour of the ThreadPool.
Anyway I wouldn't consider it "breaking", since an application based on multi-threading processing should be much more fault-tolerant about resources management, so if your application stopped working, maybe you could consider a more robust and flexible architecture.
That's just my 2 cents :)

posted by

NinjaCross 4 months, 6 days ago

BTW, I think it's a bit unfortunate that we are discussing this on dotnetkicks rather than the blog in question :)

posted by confuzatron 4 months, 6 days ago

Oops. The author subbed another "breaking change" article about the threadpool that concerned the rate of thread creation. I withdraw my previous comment.

posted by

yesthatmcgurk 4 months, 2 days ago