Having investigated this a bit further the main leak appears to be in epoll/kqueue where file descriptors in use by the queue aren't freed when the queue is dropped.

Stop leaking file descriptors #387

While this PR tidies up file descriptors, it doesn't play nice with Rust 1.80+ which has stricter checks on file descriptor use, resulting in the dreaded message

fatal runtime error: IO Safety violation: owned file descriptor already closed.

Since a crash has a greater impact on the end user than a few leaked descriptors, I would recommend against merging in this change without further investigation into duplicate closing of descriptors.

When I keep tabs on the created file descriptors and how they were created by epoll, and I close everything except the ones created with new_event then the above double close does not seem to occur. This approach somewhat alleviates the problem.

Previously my descriptor metrics were

• Before running a test: 6 descriptors open
• After running a test: 32 descriptors open

When clearing all descriptors except the new_event ones, the double close crash does not occur.
The metrics then improve to

• Before running a test: 6 descriptors open
• After running a test: 18 descriptors open

Although this alleviates the problem somewhat, it is not yet fully solved. Further investigation is needed to pinpoint the cause of the double close. It seems the descriptors created through new_event could mostly be replaced with standard threads. Perhaps some of the event callbacks can be reworked with std::thread instead of using file descriptors, as this would leave management of the file descriptors to the compiler, rather than to the developer.