expose si_status for SIGCHLD

[LunarLambda]

Problem: there is no way to get the exit status or signal of a child process when handling SIGCHLD.

Solution: expose siginfo_t's si_status field in Process when extracting info for SIGCHLD.

Let me know if I should drop or change the version bump commit. It might not be entirely correct.

closes #165

[vorner]

Apparently, the CI degraded over time, so it's failing a lot :-(. This is a change that would probably need a thorough checking over all the platforms.

How portable is this field? Is it supported on every weird platform that exists?

Also, why is it needed? When you receive a SIGCHLD, aren't you supposed to waitpid on it anyway?

As for the bump of version, it also needs a note in the changelog. And I don't think there's a need to go from 0.3 to 0.4.

[LunarLambda]

si_status is part of POSIX. However, depending on platform it might be stuffed inside of a (anonymous) union. Hence the SIGCHLD check in extract.c

Yes, you are generally meant to wait on the process to reap then, however this allows getting all the info in one place, as well as std::process::Child only allows you to wait for exit, so you can't handle things like a child processing suspending or stopping due to job control (SIGSTOP, SIGTOUT) or similar.

I can remove the version bump and add release notes. I thought it would be necessary since it adds a new public field to Process.

[vorner]

si_status is part of POSIX.

Would you have the time to look at the CI? I'm generally busy lately, and as I said, I like the change, but I'm worried about the compatibility. The fact it is defined by POSIX is a good starting point for hope, but the library already contains a few workarounds for some platforms that … have a different idea about what POSIX really is.

I thought it would be necessary since it adds a new public field to Process.

Yes, it does. But fortunately, Process is marked as non-exhaustive which prevents someone from outside of the crate from creating it by listing all the fields ‒ which ensures backwards compatibility while adding new fields.

[LunarLambda]

I had missed the struct being non_exhaustive, that's good then.

I can take a look at the CI, but I don't have a ton of experience with that. I did run cargo test over the whole workspace at least.

[blackbit42]

Bump!
This would be a very useful feature.
Besides - and please let me know if you think this is too far off-topic for this PR - it would be helpful to expose all or at least some additional fields of siginfo_t.
@LunarLambda would you be in the mood to add that?

[vorner]

Apparently, there wasn't much activity 😇. The CI got revived a bit recently, so maybe we just need to rebase it. Should I take it over?

As for „all“ the fields of siginfo_t. The problem is, platforms have different ideas of what's inside it and what exactly it means. I'm not against adding more fields in general, as long as it is done in some platform independent way (either fields that are available „everywhere“, according to CI, or that they are available conditionally only on the platforms that have them). Not sure if it belongs to this particular PR, though… it might need some iteration with the CI to check.

[blackbit42]

As for „all“ the fields of siginfo_t. The problem is, platforms have different ideas of what's inside it and what exactly it means. I'm not against adding more fields in general, as long as it is done in some platform independent way (either fields that are available „everywhere“, according to CI, or that they are available conditionally only on the platforms that have them). Not sure if it belongs to this particular PR, though… it might need some iteration with the CI to check.

Do we know what is available 'everywhere'?
I personally am primarily interested in si_uid and si_pid, FWIW.

[LunarLambda]

Apparently, there wasn't much activity 😇. The CI got revived a bit recently, so maybe we just need to rebase it. Should I take it over?

As for „all“ the fields of siginfo_t. The problem is, platforms have different ideas of what's inside it and what exactly it means. I'm not against adding more fields in general, as long as it is done in some platform independent way (either fields that are available „everywhere“, according to CI, or that they are available conditionally only on the platforms that have them). Not sure if it belongs to this particular PR, though… it might need some iteration with the CI to check.

I'm currently at a convention. I could take a look at rebasing the PR in ~32 hours or so from now. Still don't really have anything to say regarding the CI ^^. Still interested in getting this pushed through though.

[blackbit42]

Be careful with the Tschunk :-).

[vorner]

I'm currently at a convention. I could take a look at rebasing the PR in ~32 hours or so from now. Still don't really have anything to say regarding the CI ^^.

Please do so at a time of your convenience :-).

As for the CI - as I mentioned, it got revived in current master. That's why I'm suggesting to rebase it there.