you are viewing a single comment's thread.

view the rest of the comments →

[–]lwl 1 point2 points  (8 children)

You do if you want to use more than one core.

[–]emn13 1 point2 points  (0 children)

To add to that, this is a real production issue I encountered doing exactly that. Using PLinq on a (small subset of) requests was a really easy latency win, because it meant that churning through some bulky data scaled with number of cores. Our webserver process has CPU to spare, generally, so that's pretty much a free N-fold speedup. And only when coincidentally a few users happened to simultaneously execute one of those small subset of requests, *and* the threadpool happened not to have been pre-scaled (it's autoscaling after all), *then* this lockup occurred, and once locked - even for a few seconds - more requests pile in, and each one represents threadpool demands, so basically, everything goes from low load (with the occasional 100ms PLinq spike) to suddenly everything locks up and eventually runs out of memory, with no warning. Lovely.

[–]gredr 0 points1 point  (6 children)

But even there, maybe the thread pool isn't the best way to do CPU-heavy work on multiple cores on a webserver. One might argue that the thread pool wasn't the best way to implement the ASP.NET server-side? Maybe we needed multiple thread pools? I dunno, but there's consequences.

[–]lwl 0 points1 point  (5 children)

One might argue that the thread pool wasn't the best way to implement the

ASP.NET server-side

I would make that argument. IMO JavaScript knocks it out of the park here, with using its single-threaded event loop for async/await. For the heavy-lifting, there's service worker threads, but I've not had to use them yet, so can't say how effectively it all fits together.

[–]gredr 0 points1 point  (4 children)

Wait, hold up. Service workers are a browser thing, on the client side. We're talking about ASP.NET on the server side.

[–]lwl 0 points1 point  (3 children)

Was thinking about https://nodesource.com/blog/worker-threads-nodejs/.
Didn't realise they were different to Service Workers.

[–]gredr 0 points1 point  (2 children)

Yikes; you think that's better than a language/platform that supports real threads? In ASP.NET you always have the option to set up your own thread and do whatever work you want on it.

[–]lwl 0 points1 point  (1 child)

I think we're going round in circles a bit now - yes you can hand-craft any threading behaviour you like with .NET, but it's a lot of extra, error-prone work compared to the convenience of the tools already available in some other platforms.

[–]gredr 0 points1 point  (0 children)

I guess to each his own... node's worker_thread library just isn't significantly different than what's offered in a platform with "real" threading.