3 ms·

> Didn't we already discuss this? The answer is no. We did, but you never made the case for the answer being no, which means the answer is still yes. > GUI to

by mmt 8y ago

> Didn't we already discuss this? The answer is no. We did, but you never made the case for the answer being no, which means the answer is still yes. > GUI toolkits based on C/C++ could use userland-based cooperative multithreading to keep things responsive, but they don't. They use kernel threads That's descriptive, not normative. You haven't said why that's the case, or, more importantly, why, in the absence of kernel threads, someone would want them to exist only for GUI responsiveness types of use cases. Your earlier admission led me to believe they wouldn't: > Cooperative multithreading isn't a popular model in C-family languages, but I can't see a good technical reason that it wouldn't work (after all, it boils down to something akin to green threads with finer control).

MaxBarraclough 8y ago
> 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/ https://stackoverflow.com/a/16766549/ [0] https://docs.microsoft.com/en-us/windows/desktop/procthread/about-processes-and-threads https://docs.microsoft.com/en-us/windows/desktop/procthread/...
- mmt 8y ago
  > 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?
  - MaxBarraclough 8y ago
    > 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.

by mmt 8y ago

MaxBarraclough 8y ago

> 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/ https://stackoverflow.com/a/16766549/ [0] https://docs.microsoft.com/en-us/windows/desktop/procthread/about-processes-and-threads https://docs.microsoft.com/en-us/windows/desktop/procthread/...

mmt 8y ago
> 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?
- MaxBarraclough 8y ago
  > 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.