Luci RocksSep 8, 2019
fhe fact that posix and the c standard library are standard is very good. the fact that neither is actually safe to use kinda sucks, and the fact that none of it was ever designed with multiple threads or cores in mind makes broken things too easy to make.
can we do better?
Show threadhefSep 8, 2019
@zensaiyuki Doesn't posix occasionally get updated with thread related features?
Show threadLuci RocksSep 8, 2019
@hef that’s a very different thing from changing the entire system, and breaking backwards compatibility in order to create a system that is actually designed *for* threads.
Show threadLuci RocksSep 8, 2019
@hef like, yeah, sure, it’s got bolt on thread support. that’s why it sucks.
Show threadhefSep 8, 2019

@zensaiyuki I suppose that's the cost of never breaking backwards compatibility.

I've been impressed with golang's synchronization primitives being "goroutine" aware. porting that kind of system into c/c++ would be challenging to get working with old code

Show threadLuci RocksSep 8, 2019
@hef the real problem is that “thread” is a bad primitive which puts too much trust in users and programmers by default.
Show threadhef
@zensaiyuki What would be a better model?
Sep 8, 2019 at 3:57amWeb
Show threadLuci RocksSep 8, 2019
@hef there’s actually about half a dozen concurrency models you can use depending on what you need to do. just like how we didn’t just replace GOTO with one thing. we have functions, switch statements, for loops, maps/reduce and so on.
Show threadLuci RocksSep 8, 2019
@hef so, for instance, a hell of a lot can get done with just a shared nothing concurrent map function.
goroutines are another good primitive. GPU shaders.