On 17-Oct-2017, Darek Dzia=C5=82ak wrote:

Improve performance of close_all_open_files

Thank you for re-working these changes and presenting this request.

I think the increased complexity of the function here requires
increased coverage by unit tests. That's why in merge request #11 I
have extracted a lot of the code branches to separate functions, for
easier unit testing.

--=20
\ =E2=80=9CThat's the essence of science: Ask an impertinent questi=
on, |
`\ and you're on the way to the pertinent answer.=E2=80=9D =E2=
=80=94Jacob |
o__) Bronowski, _The Ascent of Man, 1973 |
Ben Finney ben@benfinney.id.au

Hi Ben,

any update on this ticket?

From my side I prefer less code.. I know that one function is a bit more complicated then dividing functionality to small parts but please notice that function is not so long and does one specific functionality and does not require to build intermediate structures (I would like to avoid iteration up to 1M event it's very cheap loop).

I think that integration test is a good idea but it's rather not a short task...

Hey -

I've been looking at using this module for some of my code, but ~25 second start times on a raspberry pi are a bit of a problem.

Why is is that this tries to close every possible fd? That seems a bit overkill when /proc/ is available.

Something like the following takes ~10ms to run in an average usecase:

    if exclude is None:
        exclude = set()
    pid = os.getpid()
    proc_fd = "/proc/{}/fd/".format(pid)
    open_files = os.listdir(proc_fd)
    for fd in [ int(x) for x in open_files ]:
        if fd not in exclude:
            close_file_descriptor_if_open(fd)

Why is is that this tries to close every possible fd?

That behaviour is described in issue #10, which is now closed by commit ebdcfe3d4281e459.

Merge request #11 supersedes this one; closing.

Why is is that this tries to close every possible fd?

That behaviour is described in issue #10, which is now closed by commit ebdcfe3.

It turns out that the large delay I was encountering was in the range calculation/iteration; I've made a pull that cuts down on the time in that by a fairly large factor.

It turns out that the large delay I was encountering was […]

Please create a new issue to fully describe the behaviour.