3 ms·

> It doesn't, I don't think it even mentions terms like latency and throughput. It only has one group of functions to allocate memory, and neither of them can

> It doesn't, I don't think it even mentions terms like latency and throughput. It only has one group of functions to allocate memory, and neither of them can be configured wrt' to what storage to allocate memory from, definitely not in terms of that storage's latency or throughput which would be very important in systems with non-uniform memory access. Compare this to eg. concept of "memory arenas" that explicitly exists in eg. Ada, but many languages have libraries to implement this idea -- in this situations, instead of using language's allocator, you'd be using something like APR's memory pools <https://apr.apache.org/docs/apr/trunk/group__apr__pools.html https://apr.apache.org/docs/apr/trunk/group__apr__pools.html>. > and that there were other significant highly concurrent codebases before that You are again confused... there weren't such codebases in C because C is bad for this. It's not because nobody wanted it. Highly concurrent codebases existed in Erlang since forever, for example. > How do they pretend so? My computer is currently running thousands of threads just fine. Threads aren't part of C language. They exist as a coping mechanism. Their authors are coping with the lack of parallelism in C, which is exactly the point I'm making. Threads exist to fix the bad design (not that they are a good fix, especially since they are designed by people who believe that there's nothing major wrong with C, and the thousand and first patch will definitely fix the remaining problems). So, not only this is a counter-argument to the point you are trying to make, it's also yet another illustration to how using C prevents designers from seeking more adequate solutions. > from memory to CPU to controllers to buses to I/O devices, that are executing in parallel. The point is not that they cannot run in parallel... The point is that C doesn't give you tools to program them to run in parallel.

jstimpfle 3y ago
> It only has one group of functions to allocate memory, and neither of them can be configured Seriously, have you done any non-trivial C programming? Because those are blatant falsehoods. You must be talking about uni level introduction to C programming, using malloc/free and thinking that's how you "allocate". > You are again confused... there weren't such codebases in C because C is bad for this. It's not because nobody wanted it. Highly concurrent codebases existed in Erlang since forever, for example. Just one example I know, take the Linux kernel which had a good amount of SMP support way before C11. I believe they still haven't switched over to the C11 memory model. > The point is not that they cannot run in parallel... The point is that C doesn't give you tools to program them to run in parallel. How come then, that my computer is running so many things, many of them written in C, in parallel?
jstimpfle 3y ago
> Threads exist to fix the bad design (not that they are a good fix, especially since they are designed by people who believe that there's nothing major wrong with C, and the thousand and first patch will definitely fix the remaining problems). The thing that needs fixing is mostly people like you, purporting falsehoods while lacking deeper understanding how it works / how it's used. Threads are a concept that exists independently from any language. They are the unit of execution that is scheduled by the OS. If a program should be multi-threaded with parallel execution (instead of only concurrent execution), by necessity you need to create multiple threads. (Or run the program multiple times in parallel and share the necessary resources, but that's much less convenient and lacks some guarantees).

jstimpfle 3y ago

> It only has one group of functions to allocate memory, and neither of them can be configured Seriously, have you done any non-trivial C programming? Because those are blatant falsehoods. You must be talking about uni level introduction to C programming, using malloc/free and thinking that's how you "allocate". > You are again confused... there weren't such codebases in C because C is bad for this. It's not because nobody wanted it. Highly concurrent codebases existed in Erlang since forever, for example. Just one example I know, take the Linux kernel which had a good amount of SMP support way before C11. I believe they still haven't switched over to the C11 memory model. > The point is not that they cannot run in parallel... The point is that C doesn't give you tools to program them to run in parallel. How come then, that my computer is running so many things, many of them written in C, in parallel?

jstimpfle 3y ago

> Threads exist to fix the bad design (not that they are a good fix, especially since they are designed by people who believe that there's nothing major wrong with C, and the thousand and first patch will definitely fix the remaining problems). The thing that needs fixing is mostly people like you, purporting falsehoods while lacking deeper understanding how it works / how it's used. Threads are a concept that exists independently from any language. They are the unit of execution that is scheduled by the OS. If a program should be multi-threaded with parallel execution (instead of only concurrent execution), by necessity you need to create multiple threads. (Or run the program multiple times in parallel and share the necessary resources, but that's much less convenient and lacks some guarantees).