[FFmpeg-devel] [PATCH v4] vvcdec: add thread executor

[James Almer]

On 8/22/2023 9:03 AM, Nuo Mi wrote:
> On Thu, Aug 17, 2023 at 12:42 AM Rémi Denis-Courmont <remi at remlab.net>
> wrote:
> 
>> Le tiistaina 15. elokuuta 2023, 17.50.13 EEST Nuo Mi a écrit :
>>> The executor design pattern was inroduced by java
>>> <
>> https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/conc
>>> urrent/Executor.html> it also adapted by python
>>> <https://docs.python.org/3/library/concurrent.futures.html>
>>> Compared to handcrafted thread pool management, it greatly simplifies the
>>> thread code. ---
>>>   libavutil/Makefile   |   2 +
>>>   libavutil/executor.c | 201 +++++++++++++++++++++++++++++++++++++++++++
>>>   libavutil/executor.h |  67 +++++++++++++++
>>>   3 files changed, 270 insertions(+)
>>>   create mode 100644 libavutil/executor.c
>>>   create mode 100644 libavutil/executor.h
>>>
>>> diff --git a/libavutil/Makefile b/libavutil/Makefile
>>> index 7828c94dc5..4711f8cde8 100644
>>> --- a/libavutil/Makefile
>>> +++ b/libavutil/Makefile
>>> @@ -31,6 +31,7 @@ HEADERS = adler32.h
>>
>>>               \ encryption_info.h
>>
>>>   \ error.h                                                       \
>> eval.h
>>>                                                       \ +
>>> executor.h                                                    \ fifo.h
>>
>>>                                                    \ file.h
>>
>>>                                        \ frame.h
>>
>>>                            \ @@ -127,6 +128,7 @@ OBJS = adler32.o
>>
>>>                                              \ encryption_info.o
>>
>>>                                     \ error.o
>>
>>>                            \ eval.o
>>
>>>                   \ +       executor.o
>>
>>>                  \ fifo.o
>>
>>>         \ file.o
>>   \
>>> file_open.o                                                      \ diff
>>> --git a/libavutil/executor.c b/libavutil/executor.c
>>> new file mode 100644
>>> index 0000000000..6b47ba0bf2
>>> --- /dev/null
>>> +++ b/libavutil/executor.c
>>> @@ -0,0 +1,201 @@
>>> +/*
>>> + * Copyright (C) 2023 Nuo Mi
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301
>>> USA + */
>>> +#include "internal.h"
>>> +#include "mem.h"
>>> +#include "thread.h"
>>> +
>>> +#include "executor.h"
>>> +
>>> +#if !HAVE_THREADS
>>> +#define pthread_create(t, a, s, ar)     0
>>
>> Err, this should probably return an error value, e.g. ENOSYS or ENOTSUP.
>>
>>> +#define pthread_join(t, r)              do {} while(0)
>>
>> ...and this should be an unreachable(), assert(0), abort() or something
>> along
>> those lines.
>>
>>> +
>>> +#define pthread_cond_init(c, a)         0
>>> +#define pthread_cond_broadcast(c)       do {} while(0)
>>> +#define pthread_cond_signal(c)          do {} while(0)
>>> +#define pthread_cond_wait(c, m)         do {} while(0)
>>> +#define pthread_cond_destroy(c)         do {} while(0)
>>> +
>>> +#define pthread_mutex_init(m, a)        0
>>> +#define pthread_mutex_lock(l)           do {} while(0)
>>> +#define pthread_mutex_unlock(l)         do {} while(0)
>>> +#define pthread_mutex_destroy(l)        do {} while(0)
>>> +#endif
>>> +
>>> +typedef struct ThreadInfo {
>>> +    AVExecutor *e;
>>> +    pthread_t thread;
>>
>> Does this even work if !HAVE_THREAD ?
> 
> Yes. The definition provided by the following include chain:
>   "mem.h"->"avutil.h"->"common.h"->"<stdlib.h>"->"<sys/types.h>"->"<bits/pthreadtypes.h>"

Why would bits/pthreadtypes.h be available if there's no pthreads?