[vlc-devel] [RFC 1/2] executor: introduce new executor API

[Romain Vimont]

On Wed, Aug 26, 2020 at 11:34:04PM +0300, Rémi Denis-Courmont wrote:
> Le keskiviikkona 26. elokuuta 2020, 23.11.08 EEST Romain Vimont a écrit :
> > > > +/**
> > > > + * Make sure that an interrupt thread is running and will consider the
> > > > + * interruption for a new task just added.
> > > > + */
> > > > +static int
> > > > +RequireInterruptThread(vlc_executor_t *executor)
> > > > +{
> > > > +    vlc_mutex_assert(&executor->lock);
> > > > +
> > > > +    if (executor->interrupt_thread_running)
> > > > +        vlc_cond_signal(&executor->interrupt_wait);
> > > > +    else
> > > > +    {
> > > > +        if (vlc_clone_detach(NULL, InterruptThreadRun, executor,
> > > > +                             VLC_THREAD_PRIORITY_LOW))
> > > 
> > > Detached threads cannot be safe in dynamically linked LibVLC. There's a
> > > risk that LibVLC will be unloaded before the thread exits, crashing the
> > > process.
> > In vlc_executor_Delete(), the threads are awaited via a condition
> > variable (nothreads_wait).
> 
> So what? Even vlc_cond_t code is in LibVLC, as is the code that handles the 
> return.

I think we can expect that all objects are correctly deleted
(libvlc_priv_t for example, which will delete the preparser, which will
delete its executor) before LibVLC is unloaded. If vlc_executor_Delete()
waits for the threads to complete, then the thread functions are
finished before LibVLC is unloaded, and there is no problem I guess.

> 
> Windows has FreeLibraryAndExitThread() to address this problem, but it's hard 
> to use and POSIX has no equivalent.
> 
> -- 
> レミ・デニ-クールモン
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel