On 05/18/2015 11:05 PM, Filipe Brandenburger wrote:
Hi,
On Mon, May 18, 2015 at 7:26 AM, Krzysztof Opasiak
wrote:
Matching between fds and list of expected paths is done in n^2
I don't think that's the case, because you can just stat() all the
names and fstat() all the fds, then sort both
Hi,
On Mon, May 18, 2015 at 7:26 AM, Krzysztof Opasiak
wrote:
> Matching between fds and list of expected paths is done in n^2
I don't think that's the case, because you can just stat() all the
names and fstat() all the fds, then sort both lists on inode numbers
and then traverse both in order m
On Mon, 18.05.15 16:26, Krzysztof Opasiak (k.opas...@samsung.com) wrote:
> >Please, let's keep this simple: LISTEN_NAMES should only carry actual
> >names, nothing else, and let's query the kernel for the actual fd
> >types.
>
> I'm not sure if doing stat() to determine how he should interpret co
On 05/15/2015 05:40 PM, Lennart Poettering wrote:
On Fri, 15.05.15 17:09, Krzysztof Opasiak (k.opas...@samsung.com) wrote:
LISTEN_NAMES environment variable contains details
about received file descriptors. Let's try to use it
instead of doing always two stats.
I am really not convinced tha
On Fri, 15.05.15 17:09, Krzysztof Opasiak (k.opas...@samsung.com) wrote:
> LISTEN_NAMES environment variable contains details
> about received file descriptors. Let's try to use it
> instead of doing always two stats.
I am really not convinced that it is a good idea to store redundant
information
LISTEN_NAMES environment variable contains details
about received file descriptors. Let's try to use it
instead of doing always two stats.
This commit reworks all sd_is_*() functions to try
parse LISTEN_NAMES variable in first step and do
stats only as fallback procedure or if field for given
fd i