Consider using a semaphore rather than a pipe on Unix?

[karlmcdowall]

Hi!

Background

I've been looking at some of the open issues on the Rust-coreutils project. In order to verify compatibility of the new Rust implementation with the established GNU implementation, the project is aiming to get all of the existing GNU-coreutils tests to pass when the tests are run against the new Rust implementations.
The specific issue I'm looking at is here - basically a couple of the tests (sort-merge-fdlimit.sh and sort-continue.sh) use ulimit to limit the number of file-descriptors available to the process under test (in this case it's the sort command).
Debugging has shown that in order to actually get the number of file descriptors required down the level that GNU-sort uses, we can't afford the two pipes that are required for the current rust-ctrlc implementation (specifically on the unix build).

Proposal

One potential solution is to use a libc anonymous semaphore rather than the pipe to signal from the signal-handler to the blocked-thread that makes the client-callback. sem_post is specified to be safe to use from a signal-handler. This removes the overhead of the two file-descriptors for the pipe used in the current implementation.

I've done a prototype implementation and it seems to work, will post that shortly as a pull-request. Hopefully that will clearly demonstrate the proposal.

Please let me know your thoughts! For my implementation I've put the pipe vs semaphore choice under a feature-flag, but maybe we don't need the pipe implementation any more with if we just go with using a semaphore? Or maybe that's too risky for everyone else out there?!

Thanks,
Karl

[karlmcdowall]

I've posted my prototype implementation here to hopefully help with the discussion.
Thanks