[vlc-devel] [PATCH 4/6] fetcher: use vlc_executor_t

Romain Vimont rom1v at videolabs.io
Tue Sep 8 17:07:54 CEST 2020


On Tue, Sep 08, 2020 at 03:54:28PM +0200, Romain Vimont wrote:
> On Tue, Sep 08, 2020 at 12:36:09PM +0200, Alexandre Janniaux wrote:
> > Hi,
> > 
> > I like the end result very much
> 
> Cool, thank you :) But I still have mixed feelings overall [1]
> 
> [1] https://mailman.videolan.org/pipermail/vlc-devel/2020-September/137226.html
> 
> > though the race condition
> > on Cancel is a bit inconvenient. I don't have any better way
> > for now anyway.
> 
> An interrupt() callback so that we could just _CancelAll() and forget?
> </troll>
> 
> (or even a vlc_interrupt_t passed as a parameter to the run() callback?)
> 
> I agree that in the end the user both requests the cancelation and
> provide the actual interruption mechanism.
> 
> But the executor knows better if interrupt() must be called and when to
> call it easily without race conditions.
> 
> Instead, here, the user has to store a list of all its submitted tasks
> for the sole purpose of canceling them all on delete.

In fact, the preparser (for example) must also store the list of its
submitted tasks for individual cancelation (input_preparser_Cancel()),
which receives a "void *id" (so it has to find the matching task). :(

> And it must cancel
> them one by one, because the executor must indicate whether the task
> has been actually dequeued or not, to avoid race conditions.
> 
> (In addition, semantically, I consider the interruption implementation
> to be part of a task: in theory, the creator of the task could be
> different from the one submitting it, even if in practice it's the same
> for our use cases.)
> 
> Regards
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list