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