4 ms·

Java may be an exception, but on Windows in general, and in .NET, every thread has its stack preallocated and is generally 256KB to 4MB by default, so spawning

Java may be an exception, but on Windows in general, and in .NET, every thread has its stack preallocated and is generally 256KB to 4MB by default, so spawning “a couple thousand threads” as you suggest will immediately consume 250MB-4GB of main-memory which adds considerable memory-pressure. That’s not something to be taken lightly. By using (true) async IO you’ll likely only need 20-50MB total because it uses the threadpool for continuations which is sized according to the actual available level of concurrency. Async NetworkStreams or Sockets in .NET is a well-designed API over traditional BSD sockets’ select() function which is how you scale to tens of thousands of concurrent connections using only as many threads as you have hardware DoP - it’s not that I’m wowed that .NET has modernised it, it’s that Java’s solution is to wallpaper over a gaping hole in their fundamental design instead.

pjmlp 5y ago
Tainting the whole call is major problem in .NET code. That is why you will find out lots of code bases full of Task.Run() and direct calls to .Result, instead of using async/await operators. Having worked with both platform since their yearly days, I am not sure which design is actually the best one, considering brown field development.
- DaiPlusPlus 5y ago
  What you’re describing is just fake-async and that is discouraged in the ecosystem. I’m not aware of any major NuGet packages that use fake-async, and certainly nothing in the BCL.
  - pjmlp 5y ago
    Not at all. What I am describing is what a large majority of .NET consulting projects do, because async/await taints the whole call stack up to Main() or event handlers, and almost no one is doing .NET Core projects from scratch. Just because it is discouraged at conference talks and blog posts, doesn't mean devs aren't doing it on the trenches when dealing with the crossfire of project deadlines and massive codebases.
    - DaiPlusPlus 5y ago
      > Just because it is discouraged at conference talks and blog posts, doesn't mean devs aren't doing it on the trenches when dealing with the crossfire of project deadlines and massive codebases. Oh, I'm sure of that, don't worry. I'm just fortunate that I've never had to experience that myself.
native_samples 5y ago
I don't see how this is wallpapering over a hole in the design. Far from it. Java has supported async IO since Java 1.4 using APIs like java.nio.channels.AsynchronousChannel. That's a more or less conventional wrapper around epoll. What's being introduced now is a way to use that API without needing to touch the whole concept of async code. From the developer's perspective blocking calls and threads is pretty nice. It's async that's awkward and hard to use. Making the existing threads facility scale much better is a very clean approach: virtual threads introduces "virtually" no new concepts at all, in fact, if you aren't working with native code via JNI or Panama then you can act as if virtual and physical threads are the same. You literally just upgrade Java and maybe flip a couple of switches and you can now assign one thread per connection yet handle millions of connections (assuming you don't run out of other resources of course).
- DaiPlusPlus 5y ago
  java.nio.channels was introduced in Java SE 7, not 1.4. It also is far from a drop-in replacement for InputStream/OutputStream. Even with Loom's green-threads (not the original green-threads) async IO in Java will be too otherworldly until Java's language designers cease their intrasigence about adding first-class support for `await`.
  - native_samples 5y ago
    I don't see how you arrived at that conclusion at all. Async/await is always strictly harder to use than green threads. Can you explain precisely why you view them as "otherworldly"?
    - DaiPlusPlus 5y ago
      "Async/await is always strictly harder to use than green threads" I'm sorry but I can't take you seriously after you say something like that.
ec109685 5y ago
Unless the stack is used, the memory of those stack threads is never resident, so it doesn’t create memory pressure.
- DaiPlusPlus 5y ago
  That depends on how the memory-pages of the stack-space of the threads is managed. That could still result in memory-fragmentation and disk-paging.
  - ec109685 5y ago
    At least the last time I tested on Java, resident memory << virtual memory as idle thread count increased.

pjmlp 5y ago

Tainting the whole call is major problem in .NET code. That is why you will find out lots of code bases full of Task.Run() and direct calls to .Result, instead of using async/await operators. Having worked with both platform since their yearly days, I am not sure which design is actually the best one, considering brown field development.

DaiPlusPlus 5y ago
What you’re describing is just fake-async and that is discouraged in the ecosystem. I’m not aware of any major NuGet packages that use fake-async, and certainly nothing in the BCL.
- pjmlp 5y ago
  Not at all. What I am describing is what a large majority of .NET consulting projects do, because async/await taints the whole call stack up to Main() or event handlers, and almost no one is doing .NET Core projects from scratch. Just because it is discouraged at conference talks and blog posts, doesn't mean devs aren't doing it on the trenches when dealing with the crossfire of project deadlines and massive codebases.
  - DaiPlusPlus 5y ago
    > Just because it is discouraged at conference talks and blog posts, doesn't mean devs aren't doing it on the trenches when dealing with the crossfire of project deadlines and massive codebases. Oh, I'm sure of that, don't worry. I'm just fortunate that I've never had to experience that myself.

native_samples 5y ago

I don't see how this is wallpapering over a hole in the design. Far from it. Java has supported async IO since Java 1.4 using APIs like java.nio.channels.AsynchronousChannel. That's a more or less conventional wrapper around epoll. What's being introduced now is a way to use that API without needing to touch the whole concept of async code. From the developer's perspective blocking calls and threads is pretty nice. It's async that's awkward and hard to use. Making the existing threads facility scale much better is a very clean approach: virtual threads introduces "virtually" no new concepts at all, in fact, if you aren't working with native code via JNI or Panama then you can act as if virtual and physical threads are the same. You literally just upgrade Java and maybe flip a couple of switches and you can now assign one thread per connection yet handle millions of connections (assuming you don't run out of other resources of course).

DaiPlusPlus 5y ago
java.nio.channels was introduced in Java SE 7, not 1.4. It also is far from a drop-in replacement for InputStream/OutputStream. Even with Loom's green-threads (not the original green-threads) async IO in Java will be too otherworldly until Java's language designers cease their intrasigence about adding first-class support for `await`.
- native_samples 5y ago
  I don't see how you arrived at that conclusion at all. Async/await is always strictly harder to use than green threads. Can you explain precisely why you view them as "otherworldly"?
  - DaiPlusPlus 5y ago
    "Async/await is always strictly harder to use than green threads" I'm sorry but I can't take you seriously after you say something like that.

ec109685 5y ago

Unless the stack is used, the memory of those stack threads is never resident, so it doesn’t create memory pressure.

DaiPlusPlus 5y ago
That depends on how the memory-pages of the stack-space of the threads is managed. That could still result in memory-fragmentation and disk-paging.
- ec109685 5y ago
  At least the last time I tested on Java, resident memory << virtual memory as idle thread count increased.