[vlc-devel] [PATCH 4/6] fetcher: use vlc_executor_t
Alexandre Janniaux
ajanni at videolabs.io
Tue Sep 8 16:14:14 CEST 2020
Hi,
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?)
If it were just for me, I'd just have removed cancellation of tasks
but it seems everybody wants it here. :D
The issue is not really about the cancellation itself though, but
the release of the resources after cancellation.
> 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. 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.)
In theory you can write any pattern, it just changed the amount
of time you need to invest when maintaining it. :)
Regards,
--
Alexandre Janniaux
Videolabs
More information about the vlc-devel
mailing list