Consider the following sequence of events: 1. WorkQueue::scheduleWork is called, scheduling the work to be asynchronously executed on a dispatch queue 2. The WorkQueue is destroyed 3. The dispatch queue calls WorkItem::executeWorkItem executeWorkItem will dereference the destroyed WorkQueue. This could lead to crashes.
<rdar://problem/8358511>
Once bug 43150 is fixed, this will affect Windows, too.
Maybe we should add a handle object that holds a weak reference to the WorkQueue. The handle is what gets passed to executeWorkItem. When WorkQueue gets invalidated, it can null out the handle's weak reference.
Yeah that sounds good to me.
This same bug exists on Windows.
...as I said it would in comment 2. :-)
It isn't clear to me what the expected behavior of WorkQueue::invalidate is. Possible behaviors include: 1) No WorkItems will start executing after WorkQueue::invalidate returns. 2) No WorkItems will be currently executing after WorkQueue::invalidate returns. (1) seems like it must be intended. But what about (2)? Anders?
Anders says (1) is intended, but not (2). It is up to callers to deal with a WorkItem being in progress when WorkQueue::invalidate is called. One convenience for most callers is that member-function WorkItems ref the object they're going to call, so those objects don't have to worry about being deleted in the middle of a WorkItem executing.
http://trac.webkit.org/changeset/141497 changed the semantics of WorkQueue; it's now a ref-counted class that's implicitly kept alive when executing blocks.