SPIN inside -[WebCoreNSURLSession dealloc]
<rdar://problem/27122716>
Created attachment 282513 [details] Patch
Comment on attachment 282513 [details] Patch Alternatively, you could just move the declaration of function inside the while loop scope (but not in the lock scope).
(In reply to comment #3) > Comment on attachment 282513 [details] > Patch > > Alternatively, you could just move the declaration of function inside the > while loop scope (but not in the lock scope). I considered that, but thought this way would be slightly less expensive (no call to the constructor and destructor), as well as is more explicit about what's going on.
Comment on attachment 282513 [details] Patch Clearing flags on attachment: 282513 Committed r202736: <http://trac.webkit.org/changeset/202736>
All reviewed patches have been landed. Closing bug.
Comment on attachment 282513 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=282513&action=review > Source/WTF/wtf/MainThread.cpp:137 > + // Clearing the function can have side effects, so do so outside of the lock above. > + function = nullptr; Can we just move the declaration of function inside the loop? That's the C++ way to specify the semantics you want: Don't allow this value to outlive this loop body.
> > Alternatively, you could just move the declaration of function inside the > > while loop scope (but not in the lock scope). > > > I considered that, but thought this way would be slightly less expensive (no > call to the constructor and destructor), as well as is more explicit about > what's going on. There's no performance concern here. The empty constructor just assigns nullptr, which is exactly what you've done manually. Actually, there's a slight performance win, since it's much easier for the compiler to notice that nullptr is never observed, and eliminate the store entirely.
(In reply to comment #8) > > > Alternatively, you could just move the declaration of function inside the > > > while loop scope (but not in the lock scope). > > > > > > I considered that, but thought this way would be slightly less expensive (no > > call to the constructor and destructor), as well as is more explicit about > > what's going on. > > There's no performance concern here. The empty constructor just assigns > nullptr, which is exactly what you've done manually. Actually, there's a > slight performance win, since it's much easier for the compiler to notice > that nullptr is never observed, and eliminate the store entirely. Okay, sure. I'll post a follow up.