Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled file descriptors

[Alexey Budankov]

On 03.06.2020 15:30, Hunter, Adrian wrote:
> 
> 
>> -----Original Message-----
>> From: Hunter, Adrian <adrian.hunter@xxxxxxxxx>
>> Sent: Wednesday, June 3, 2020 3:24 PM
>> To: Alexey Budankov <alexey.budankov@xxxxxxxxxxxxxxx>
>> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>; Jiri Olsa
>> <jolsa@xxxxxxxxxx>; Namhyung Kim <namhyung@xxxxxxxxxx>; Alexander
>> Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>; Peter Zijlstra
>> <peterz@xxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Andi Kleen
>> <ak@xxxxxxxxxxxxxxx>; linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>
>> Subject: Re: [PATCH v6 01/13] tools/libperf: introduce notion of static polled
>> file descriptors
>>
>> On 3/06/20 3:01 pm, Alexey Budankov wrote:
>>> Hi,
>>>
>>> On 03.06.2020 14:38, Adrian Hunter wrote:
>>>> On 1/06/20 11:05 pm, Alexey Budankov wrote:
>>>>>
>>>>> Implement adding of file descriptors by fdarray__add_stat() to
>>>>> fix-sized (currently 1) stat_entries array located at struct fdarray.
>>>>> Append added file descriptors to the array used by poll() syscall
>>>>> during fdarray__poll() call. Copy poll() result of the added
>>>>> descriptors from the array back to the storage for separate analysis.
>>>>
>>>> Why not instead call evlist__add_pollfd() before other fds are added,
>>>> so the fda->entries[] position is always fixed. Then this patch is not
>> needed.
>>>
>>> It then will block event consumption loop, at least in record mode,
>>> due to change sin initial assumptions behind fdarray__filter(). So
>>> extension of the API with 'static' fds looks safer w.r.t. possible
>>> functional regressions at the same time extending the API with ability
>>> to atomically wait for (poll()) not only event fds but also any other fds
>> during monitoring.
>>
>> So make fdarray__filter() return the number of filterable fds remaining.
>>
> 
> 
> Or perhaps simpler, compare the return value to the number of fds that are known not to be filterable

Well, various implementations are for sure possible but the proposed design
avoids implicit code assumptions and dependency on API calls order as in API
implementation as in client code and that is why it's been proposed this way.