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

[Alexandre Janniaux]

Hi,

On Tue, Sep 08, 2020 at 04:33:58PM +0200, Romain Vimont wrote:
> On Tue, Sep 08, 2020 at 04:14:14PM +0200, Alexandre Janniaux wrote:
> > 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
>
> Yes, if I close VLC, I don't want it to wait a fetching task taking
> seconds or minutes because a server does not respond.

Having cancellation of tasks is different from the cancellation of
the pending IO.

> > The issue is not really about the cancellation itself though, but
> > the release of the resources after cancellation.
>
> I'm not sure, it's about both, especially when to call interrupt().

Not really, you could have a cleanup callback that is not an interrupt
callback, but it means that you will need refcounting as soon as you
want to queue the same state multiple times. The difference is that the
interrupt callback is called asynchronously with the task while the
cleanup callback is called synchronously.

Regards,
--
Alexandre Janniaux
Videolabs