DIP 1024--Shared Atomics--Community Review Round 1
Ola Fosheim Grøstad
ola.fosheim.grostad at gmail.com
Sat Oct 12 11:26:42 UTC 2019
On Saturday, 12 October 2019 at 09:45:41 UTC, Jonathan M Davis
> It's the same as with any @trusted code. It's up to the
> programmer to ensure that what the code is doing is actually
> @safe, and if the code isn't able to provide an API that is
> @safe, then it shouldn't be @trusted.
So, I am trying to figure out what that API would have to look
like and the only solution I can think of right away is that you
have are doing a callback back into @safe code from the
lock-holding @trusted code?
So, if you have to obtain locks from multiple sources, it either
won't work out, or you have to use some serious kludges, like a
deep call chain:
safe_code_callback2 processes and sets
Of course, that could lead to starvation.
So to avoid all of that multi-threaded libraries have to have 2
APIs, one simple transactional wrapper-API for @safe code and
another API for @trusted code that can be used to write a new
wrapper that allows locking of multiple datastructures.
I hope people try to sketch out what such libraries will look
like before the semantics are decided on. Maybe an experimental
branch would be appropriate.
More information about the Digitalmars-d