[vlc-devel] [RFC 0/2] New executor API

[Romain Vimont]

On Fri, Aug 28, 2020 at 06:09:30PM +0200, Pierre Ynard via vlc-devel wrote:
> Date: Fri, 28 Aug 2020 18:09:30 +0200
> From: Pierre Ynard <linkfanel at yahoo.fr>
> To: vlc-devel at videolan.org
> Subject: Re: [vlc-devel] [RFC 0/2] New executor API
> User-Agent: Mutt/1.5.23 (2014-03-12)
> 
> > In the case the vlc_executor is killed, the preparser client needs to
> > be killed first since it is using the executor, and thus can cancel
> > its tasks internally directly, which might be at the middle of the
> > preprocessing, at the beginning or right before the end. It's much
> > less convoluted than having the preparser client use the vlc_executor
> > to cancel the taks, which will just really call the preparser specific
> > cancellation code anyway.
> 
> I'm not sure what your point is, but the vlc_executor can be killed
> without killing its users first: it just needs to stop accepting new
> tasks, then cancel/time out/wait out all current tasks, then join all
> its worker threads and exit.
> 
> Now if each user wants to create and use its own dedicated executor and
> thread pool, then obviously it would kill its dedicated executor before
> killing itself; but it might make more sense that the core provides a
> single executor instance with a common thread pool, and keep it hidden
> behind the API, in which case users hold no reference to the executor.

That's a good point (we _could_ use the same executor for preparser,
fetcher and thumbnailer). But even in that case, the owner of the
executor may know the submitted tasks, so it is still able to cancel
them on deletion.

> 
> -- 
> Pierre Ynard
> "Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel