[PATCH] D21889: [tsan] Add support for GCD IO channels on Darwin

Kuba Brecka via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 8 14:10:42 PDT 2016

kubabrecka added inline comments.

Comment at: lib/tsan/rtl/tsan_libdispatch_mac.cc:512
@@ +511,3 @@
+  SCOPED_TSAN_INTERCEPTOR(dispatch_read, fd, length, q, h);
+  __block tsan_block_context_t new_context = {
+      q, nullptr, &invoke_block, false, false, false, 0};
dvyukov wrote:
> Here is something I am missing.
> Is new_context captured by reference or by value? Internet says that __block makes it captured by reference. But then doesn't new_h refer to a dangling stack location? new_context is stack allocated in this function, but new_h will be executed some time later.
> And if it is captured by value, then synchronizing on address &new_context is pointless -- closure will have a different address.
> What am I missing?
`__block` turns the variable into a reference-counted object that is captured by reference.  It’s actually allocated as part of the block.  When the block is promoted to a heap object (via Block_copy), the variable is promoted as well.  Note that `&new_context` is different before the Block_copy and after it (before it points to the stack, after it points to the heap).

Does this make sense?  You can take a look at this via `clang -rewrite-objc file.m -o -` which will rewrite all Obj-C and all block stuff into pure C/C++ code.  But the full mechanism is pretty complex and the generated code is hard to read.


More information about the llvm-commits mailing list