Maybe solves the hardest parts. Safe, lock-free shared memory via compile-time data ownership checks. Watching with interest
-
-
Replying to @nathanstocks
Ok, I think message passing concurrency is too limited and manual for complex code, e.g. updating actors in a game engine.
2 replies 0 retweets 0 likes -
Replying to @TimSweeneyEpic
What if the message were the actor itself - no copying. Lock-free passing ownership of shared memory - powerful and fast
1 reply 0 retweets 0 likes -
Replying to @nathanstocks
The worst case is: a bunch of threads updating random sets of objects whose interdependencies aren't known a priori.
2 replies 0 retweets 0 likes -
Replying to @TimSweeneyEpic
Classic deadlock. I see the root of your desire for transactional memory.
1 reply 0 retweets 0 likes -
Replying to @nathanstocks
Cool. Most people judge it infeasibly costly, but I think that's an artifact of C++'s "everything is mutable by default".
1 reply 0 retweets 0 likes -
Replying to @TimSweeneyEpic @nathanstocks
Because of the overhead transactional memory adds, you really need a language design that's amenable to mostly const data.
2 replies 0 retweets 1 like -
-
Replying to @nathanstocks @TimSweeneyEpic
In other words, are you considering a transactional subsystem written in a functional language, or engine rewrite?
1 reply 0 retweets 0 likes -
Replying to @nathanstocks
I think you need a new language to do this uber concurrency gainfully. This is vey much not on the UE roadmap right now.
2 replies 0 retweets 0 likes
I don't see anyone doing this the way it needs to be done, though various languages address isolated parts of it.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.