On Friday, 21 July 2017 at 11:57:11 UTC, Kagamin wrote:
On Friday, 21 July 2017 at 08:51:27 UTC, Atila Neves wrote:
Mutexes and sockets are classes, so not destroyed
deterministically.
They should, like any unmanaged resources, e.g. by wrapping in
a smart pointer. Imagine 10000 lingering tcp connections
accumulated over time due to poor timing of destruction, it
becomes a stress test for the server.
Anything that is `shared` is likely to be a reference
(pointer, class...), or a global. Either way the
compiler-generated destructor call isn't going to exist, which
means it's probably ok to cast away shared when the compiler
inserts the automatic call to a destructor at the end of scope.
These are contradictory. Does the automatic destructor call
exist or not?
What I'm trying to say is that `shared` values will usually be
references or globals and therefore there won't be a
compiler-generated call to the destructor at the end of scope.
When the compiler _does_ generate a call to the destructor, the
value is unlikely to be shared.
Since then I've thought that sending a value to another thread
does indeed create a shared value with defined scope. Or, for
that matter, calling any function that takes shared values (but
those are rare, so it'll usually be `send`).
I think I've not done a good job of explaining the destructor
fix: what it changes is the code the compiler writes for you when
variables go out of scope, i.e. the automatic destructor call
casts away shared. It already did the same thing for immutable,
otherwise you wouldn't be able to put immutable values on the
stack.
Atila
