http://d.puremagic.com/issues/show_bug.cgi?id=4621
--- 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 4624). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------