4 ms·
This reminds me of this poster: "You must be this tall..." https://bholley.net/blog/2015/must-be-this-tall-to-write-multi-threaded-code.html https://bholley.ne
by bb88 3y ago
This reminds me of this poster: "You must be this tall..."
https://bholley.net/blog/2015/must-be-this-tall-to-write-multi-threaded-code.html https://bholley.net/blog/2015/must-be-this-tall-to-write-mul...
Back about a decade ago I was "auditing" someone else's threaded code. And couldn't figure it out. But he was the company's "golden child" so by default it must be working code because he wrote it.
And then it started causing deadlocks in prod.
"What do you want me to do about it? It's the golden child's code. He's not even gonna show up til 2pm today."
- wmf 3y agoThe thing is... multi-process with a bespoke shared memory system isn't better than multithreading; it's much worse.
- anarazel 3y agoI'm not sure if I'd judge it as harshly, but you have a good point: A lot of debugging / validation tooling understands threads, but not memory shared between processes.
- throwawaylinux 3y agoBy bespoke you mean using standard interfaces to create shared memory pools? They do roll some of their own locking primitives, but that's not particularly unusual in a large portable program (and quite likely what they wanted is/was not available in glibc or other standard libraries, at least when first written).
- __turbobrew__ 3y agoIn Linux, multi process with shared memory regions is basically just threads. The kernel doesn’t know anything about threads, it knows about processes and it lets you share memory regions between those processes if you so desire.
- paulddraper 3y agoIt kinda is though. The process barrier is better at enforcing careful deliberate interactions
- citrin_ru 3y agoThe difference is between everything shared (threads) and some parts are shared explicitly (processes with shared memory). I'm not sure 2nd is worse.