[Issue 4621] Destructors are inherently un- at safe

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=4621



--- Comment #16 from Michel Fortin <michel.fortin at michelf.com> 2010-08-12 12:30:40 EDT ---
(In reply to comment #15)
> Running on a different thread still makes a severe difference to shared or C
> data. C APIs usually aren't thread-safe. For some OS APIs, the caller thread
> makes a difference (for instance, you'd break OS provided TLS).

This depends on the meaning of shared vs. non-shared. Is a non-shared object
guarantied to always exist in the same thread? Or is it only guarantied to be
accessible in one thread at a time? The former would forbid objects with a
unique reference to a non-shared memory block from being moved from one thread
to another with no copying, so I think the later is more useful.

> You'll have to make an explicit exception in the language spec for finalizers
> to allow this.

With the "accessible in one thread at a time" model, the only additional
special case with multithreading is that you can't access non-shared memory
referenced by a member if there's a chance this memory might still be in
referenced by the original thread. Combine this with the problem of GC-managed
memory which could have already be deallocated and multithreading only
complicates the case where you have manually managed memory shared between
objects (such as reference counting)...

... and I think I've found such a bug in std.containers.Array (added to bug
4624).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------