> you never made the case for the answer being no, which means the answer is still yes
The widespread use of preemptive concurrency for reasons aside from parallelism, demonstrates my point.
> You haven't said why that's the case
If I had to guess, I'd go with this: it's the easiest option for the C/C++ languages and developers, considering how existing functions tend to be blocking, and that C/C++ programmers are more likely to be familiar with preemptive concurrency than cooperative concurrency.
You certainly wouldn't want to use a model that relies on, say, continuations. Intel's TBB library does this. It's a very good library, but the user must write pretty hairy C++ code, despite the benefits of modern C++. It's no help that continuations are trivial in, say, modern C#.
Fibers/coroutines can be done with external C/C++ libraries, but it's seen as a pretty exotic thing to do.
> why, in the absence of kernel threads, someone would want them to exist only for GUI responsiveness types of use cases
Looks like Windows first got 'proper threads' in Windows 98. I suspect it's not purely for GUI, but for other types of application too, such as servers. Again I suspect the reason they're used in preference over the cooperative alternative, is largely just what people are used to.
Looks like Windows provides fibers for C++, so it's not like they've never heard of them. [0]
> Your earlier admission led me to believe they wouldn't:
Sure, I'm not hating on cooperative multithreading. They have advantages: fine-grain user control, no unexpected interleaving, better performance regarding switching. Bit of a pity it's not often used, I suppose.
I google'd the question, but didn't find a decent exploration of why they're so rarely used. This StackOverflow answer thinks the answer is technical, but I'm not convinced. It seems to discount asynchronous IO. https://stackoverflow.com/a/16766549/
> The widespread use of preemptive concurrency for reasons aside from parallelism, demonstrates my point.
If your point is that kernel threads are more attractive that the alternative, once they already exist, then yes, but that continues to miss refuting my assertion.
Using something ("off label"[1]) once it's already there, isn't the same thing as wanting/needing it in the first place.
[1] consistent with my assertion that the "label" for threading specifies its use for multiprocessor support. After all, how did the early X server or Sun's NeWS manage to be so responsive before all that newfangled threading stuff in the 90s?
> how did the early X server or Sun's NeWS manage to be so responsive before all that newfangled threading stuff in the 90s?
Good question. I have no idea.
If my intuition is accurate, systems like the DOOM engine just crunch through each frame's workload as a sequential queue, tending to things like the audio buffer whenever necessary. I don't know if there's any asynchronous code to speak of in there.
The widespread use of preemptive concurrency for reasons aside from parallelism, demonstrates my point.
> You haven't said why that's the case
If I had to guess, I'd go with this: it's the easiest option for the C/C++ languages and developers, considering how existing functions tend to be blocking, and that C/C++ programmers are more likely to be familiar with preemptive concurrency than cooperative concurrency.
You certainly wouldn't want to use a model that relies on, say, continuations. Intel's TBB library does this. It's a very good library, but the user must write pretty hairy C++ code, despite the benefits of modern C++. It's no help that continuations are trivial in, say, modern C#.
Fibers/coroutines can be done with external C/C++ libraries, but it's seen as a pretty exotic thing to do.
> why, in the absence of kernel threads, someone would want them to exist only for GUI responsiveness types of use cases
Looks like Windows first got 'proper threads' in Windows 98. I suspect it's not purely for GUI, but for other types of application too, such as servers. Again I suspect the reason they're used in preference over the cooperative alternative, is largely just what people are used to.
Looks like Windows provides fibers for C++, so it's not like they've never heard of them. [0]
> Your earlier admission led me to believe they wouldn't:
Sure, I'm not hating on cooperative multithreading. They have advantages: fine-grain user control, no unexpected interleaving, better performance regarding switching. Bit of a pity it's not often used, I suppose.
I google'd the question, but didn't find a decent exploration of why they're so rarely used. This StackOverflow answer thinks the answer is technical, but I'm not convinced. It seems to discount asynchronous IO. https://stackoverflow.com/a/16766549/
[0] https://docs.microsoft.com/en-us/windows/desktop/procthread/...