--- Comment #16 from Michel Fortin <michel.for...@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
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------