Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot access the si_pid field from waitid() call. #1381

Closed
gatoWololo opened this issue May 29, 2019 · 4 comments
Closed

Cannot access the si_pid field from waitid() call. #1381

gatoWololo opened this issue May 29, 2019 · 4 comments

Comments

@gatoWololo
Copy link

Hello!

I'm trying call waitid() from libc like:

let mut siginfo: libc::siginfo_t = unsafe { std::mem::zeroed() };
let ignored = 0;
libc::waitid(libc::P_ALL, ignored, &mut siginfo as *mut libc::siginfo_t , libc::WNOWAIT | libc::WEXITED | libc::WSTOPPED )

I use waitid() instead of waitpid() or wait() since I want the WNOWAIT flag. According to man 2 waitid:

Upon  successful  return,  waitid()  fills  in the following fields of the siginfo_t
       structure pointed to by infop:

       si_pid      The process ID of the child.

However, looking at the declaration of sigino_t for Rust libc, it seems there is no si_pid field available. I know this is related to how sigino_t is defined #716.

Currently I'm linking out to C to get the correct field. It's ugly but it works.

pid_t getPid(siginfo_t* infop) {
  return infop->si_pid;
}

I would like to transmute/cast the struct in Rust, but I have no idea what the si_pid-containing version of siginfo_t looks like.

@gnzlbg
Copy link
Contributor

gnzlbg commented May 29, 2019

I think we should just add methods to siginfo in Rust that do the union access internally.

@joshtriplett
Copy link
Member

I just ran into this myself. I need access to si_pid for use with libc::WNOHANG: when calling waitid with WNOHANG, you have to check if si_pid == 0 to tell if you have a process status or if waitid has returned immediately because there aren't any waitable processes.

Long-term, I'd love to have the fields defined, but short-term, I'd settle for a method that returns the appropriate field value.

@joshtriplett
Copy link
Member

#1858 should fix this.

@JohnTitor
Copy link
Member

I'm going to close this as fixed by #1858.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants