On 7/7/24 1:46 PM, Stephen Hutchinson wrote:
On 7/7/24 9:50 AM, Andreas Rheinhardt wrote:
avisynth_context_destroy() is currently always called while holding the
lock (i.e. avisynth_mutex). Is this even necessary? It is clear that
avisynth_load_library() (and the check for whether it should be called)
need the lock, but does anything else (like
avs_create_script_environment) really need it?
Threading control is a topic that definitely goes over my head, so
my honest answer would be that I don't know. But what I would say is
that if I correctly understand the order of execution inside the
demuxer, library, and script environment, AviSynth loading its own
plugins occurs after avs_create_script_environment is called in the
client program.
If avs_load_library and its check need the lock in place,
is it supposed to be assumed that then AviSynth handles
loading/unloading its plugins purely on its own without the
overarching lock, or is that cascaded loading something that
needs the lock in place throughout the process (because
avisynth_context_destroy is what ultimately calls
avs_delete_script_environment and unloads whatever plugins were
loaded by AviSynth)?
I've sent a second patch to remove the lock requirement in
avisynth_read_close.
The atexit patch was separate anyway, and if there's no
objections raised, I'll push that one in a day or two,
or wait a little longer and push both at the same time
if the lock change is fine.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
