Socket and spawn()

[Andy Valencia]

On Friday, 31 May 2024 at 16:59:08 UTC, Jonathan M Davis wrote:
> Strictly speaking, unless you're dealing with a module or 
> static-level variable, the object is not in TLS. It's treated 
> as thread-local by the type system, and the type system will 
> assume that no other thread has access to it, but you can 
> freely cast it to shared or immutable and pass it across 
> threads. It's just that it's up to you to make sure that you 
> don't have a thread-local reference to shared data that isn't 
> protected in a fashion that accessing the thread-local 
> references is guarantee to be thread-safe (e.g. the appropriate 
> mutex has been locked).

Thank you; this is the most complete explanation I've found yet 
for hwo to look at data sharing in D.

> On the other hand, if you're actively sharing an object across 
> threads, then you cast it to shared and give it to the other 
> thread. But then you have to use an appropriate 
> thread-synchronization mechanism (likely a mutex in the case of 
> a socket) to ensure that accessing the object is thread-safe.

Speaking as an old kernel engineer for the Sequent multiprocessor 
product line, this is all very comfortable to me.  I'm very glad 
that D has a suitable selection of spinlocks, process semaphores, 
and memory atomic operations.  I can work with this!

> In any case, you can freely cast between thread-local and 
> shared. It's just that you need to be sure that when you do 
> that, you're not violating the type system by having a 
> thread-local reference to shared data access that shared data 
> without first protecting it with a mutex.

That was the trick for me; TLS implied to me that an 
implementation would be free to arrange that the address of a 
variable in one thread's TLS would not necessarily be accessible 
from another thread.  Now I'm clearer on the usage of the term 
WRT the D runtime.  All good.

Thanks again,
Andy