[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