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

Steve Lhomme robux4 at ycbcr.xyz
Thu Aug 27 11:37:14 CEST 2020


On 2020-08-27 10:23, Romain Vimont wrote:
> On Thu, Aug 27, 2020 at 07:09:00AM +0200, Steve Lhomme wrote:
>> On 2020-08-26 19:19, Romain Vimont wrote:
>>> Introduce a new API to execute "runnables". The execution can be
>>> automatically interrupted on timeout or via an explicit cancelation
>>> request.
>>> ---
>>>    include/vlc_executor.h | 194 +++++++++++++++
>>>    src/Makefile.am        |   1 +
>>>    src/libvlccore.sym     |   4 +
>>>    src/misc/executor.c    | 545 +++++++++++++++++++++++++++++++++++++++++
>>>    4 files changed, 744 insertions(+)
>>>    create mode 100644 include/vlc_executor.h
>>>    create mode 100644 src/misc/executor.c
>>>
>>> diff --git a/include/vlc_executor.h b/include/vlc_executor.h
>>> new file mode 100644
>>> index 0000000000..4dd8b93628
>>> --- /dev/null
>>> +++ b/include/vlc_executor.h
>>> @@ -0,0 +1,194 @@
>>> +/*****************************************************************************
>>> + * vlc_executor.h
>>> + *****************************************************************************
>>> + * Copyright (C) 2020 Videolabs, VLC authors and VideoLAN
>>> + *
>>> + * This program 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.
>>> + *
>>> + * This program 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 this program; if not, write to the Free Software Foundation,
>>> + * Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301, USA.
>>> + *****************************************************************************/
>>> +
>>> +#ifndef VLC_EXECUTOR_H
>>> +#define VLC_EXECUTOR_H
>>> +
>>> +#include <vlc_common.h>
>>> +#include <vlc_tick.h>
>>> +
>>> +# ifdef __cplusplus
>>> +extern "C" {
>>> +# endif
>>> +
>>> +/** Executor type (opaque) */
>>> +typedef struct vlc_executor vlc_executor_t;
>>> +
>>> +/**
>>> + * A Runnable is intended to be run from another thread by an executor.
>>> + */
>>> +struct vlc_runnable {
>>> +
>>> +    /**
>>> +     * This function is to be executed by a vlc_executor_t.
>>> +     *
>>> +     * It must implement the actions (arbitrarily long) to execute from an
>>> +     * executor thread, synchronously. As soon as run() returns, the execution
>>> +     * of this runnable is complete.
>>> +     *
>>> +     * After the runnable is submitted to an executor via
>>> +     * vlc_executor_Submit(), the run() function is executed at most once (zero
>>> +     * if the execution is canceled before it was started).
>>> +     *
>>> +     * It may not be NULL.
>>> +     *
>>> +     * \param userdata the userdata provided to vlc_executor_Submit()
>>> +     */
>>> +    void
>>
>> Why
>>
>>> +    (*run)(void *userdata);
>>
>> Do you
>> use two lines
>> for this ?
>>
>> When grepping for code I always stumble such unreadable lines. I have to
>> open the files for each of them to read the actual prototype.
> 
> We adopted this "code style" with Thomas on the playlist/player.
> 
> The reason is that the content before the function name may be very
> long, and we always align the arguments when there is not enough space:
> 
> static inline const struct vlc_something_t *vlc_something_GetSomething(struct vlc_something_t *something,
>                                                                         vlc_tick_t tick,
>                                                                         const char *yet_another_arg);
> 
> I prefer:
> 
> static inline const struct vlc_something_t *
> vlc_something_GetSomething(struct vlc_something_t *something,
>                             vlc_tick_t tick,
>                             const char *yet_another_arg);
> 
> (both if the column width limit is 80 or 100 chars)
> 
> For consistency, I do the same even for a simple "void".

A rule (that you decided on your own) that makes rare cases OK and 
normal cases horrible is not a good rule.


More information about the vlc-devel mailing list