[vlc-devel] [RFC v2 1/2] executor: introduce new executor API

[Steve Lhomme]

>>>>> just for that. I don't want to add a separate "deactivate" function for
>>>>> closing before _Delete(). Maybe the threads should continue to dequeue
>>>>> the pending tasks until the queue is empty in case a runnable queues
>>>>> another one after "closing"?
>>>>
>>>> In fact, I think it is reasonable to assert that the executor is not
>>>> closing. It is the caller responsibility to ensure that a runnable is
>>>> not submitted after it called vlc_executor_Delete().
>>>
>>> I agree, you don't want to Delete the executor while you still have
>>> pending tasks.
>>
>> That means any runnable that want to launch another runnable will need to
>> check if the executor is not canceled.
> 
> Yes. But this is the same "component" which provides the run() function
> and which calls vlc_executor_Delete().

I don't fully understand. But that doesn't sound right. That means the 
design is too tied to very narrow specific cases. (ie not chaining tasks)

>> And yet if it's not canceled it may
>> submit a task when the executor just got canceled (by another thread). And
> 
> s/canceled/deleted/
> 
>> you will end up in this assert.
> 
> It is the responsibility of the caller not to submit tasks once
> vlc_executor_Delete() is called.

But there's a race condition, as explained (twice).