Prime sieve language race
Sebastiaan Koppe
mail at skoppe.eu
Thu Jul 15 13:16:01 UTC 2021
On Thursday, 15 July 2021 at 12:35:29 UTC, Petar Kirov
[ZombineDev] wrote:
> On Wednesday, 14 July 2021 at 19:10:55 UTC, Sebastiaan Koppe
>> Because member functions are harder to call from multiple
>> threads than static functions are. For one, you will have to
>> get the object on two threads first. Most functions that do
>> that require a shared object, which requires a diligent
>> programmer to do the casting.
>
> The problem with `std.stdio : std{in,out,err}` is they ought to
> be defined (conceptually) as `shared Atomic!File`, where `File`
> is essentially a wrapper around `SharedPtr!FileState` (and
> `SharedPtr` does atomic ref-counting, if it's `shared`) and
> until then, they shouldn't be `@trusted`, unless the program is
> single-threaded.
Yes that is the sensible thing to do. But I am not sure that is
the right thing. I am afraid that it will lead to the conclusion
that everything needs to be shared, because who is going to stop
someone from taking your struct/class/function, moving it over to
another thread and then complain it corrupts memory while it was
advertised as having a @safe interface?
More information about the Digitalmars-d
mailing list