.NET 3.5 Brings BREAKING Changes to ThreadPool

home
clr
view story

15 Kicks

Kick It

Drop Kick

Kicked

.NET 3.5 Brings BREAKING Changes to ThreadPool(michaelckennedy.net)

submitted by mkennedy66996693(480) 3 years, 11 months ago

Things get more interesting with the .NET 2.0 SP1 ThreadPool.

8 comments |category: CLR |Views: 142
Tweet

tags: .net3.5 3.5 CLR ThreadPool another

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:

JonnyRocks(0) -

blacksauron(0) -

AdeBt(0) -

ChadMoran(535)

More who kicked this story...

Comments:

posted by yesthatmcgurk(4063) 3 years, 11 months ago 0

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

posted by mkennedy66996693(480) 3 years, 11 months ago 0

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 confuzatron(0) 3 years, 11 months ago 0

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(0) 3 years, 11 months ago 0

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

posted by NinjaCross(25) 3 years, 11 months ago 0

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 confuzatron(0) 3 years, 11 months ago 0

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

posted by yesthatmcgurk(4063) 3 years, 11 months ago 0

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

Most Active Users

What's this?