Checking status of fork()'d child

[Nach]

Anyone know how to fork() and have the parent know wether the child process is still running the same app, or if the child succeded in running an exec*() and is now a different app?

[DataPath]

You'll probably want to make a signal handler for SIGCHLD calls, which signal gets sent when a child process terminates

here's a quick (and completely beside the point) example (that I'm now removing)

[snip]

edit: Ohh... I see your dilemma - the child process won't have exited because of an exec... crap

[Nach]

How does that answer my question?
You don't have a single exec*() call in your example.
You never check what's with the child while it is running, only after it terminated.

[odditude]

I might be completely off here, since I haven't coded in a while and it's been YEARS since I've touched fork() at all, but...

Could you create a pipe before the fork() call, and have the child drop an "I'm exec()ing" message on the pipe immediately before the exec() call? There's a limitation here (still not sure if exec() succeeded), but at least you'd know for sure that the child got to that point without getting borked somewhere.

In the meantime, I'm hunting for something a little more complete.

(edit)
Ok, have an idea here. If you use the parent process to exec() instead of the child, then you can pass the PID of the child to the new exec'd process as an argument. If you've set up a signal handler in the child (or earlier), you can then pass a signal to the child process. Would that work here?

[Nach]

Could you create a pipe before the fork() call, and have the child drop an "I'm exec()ing" message on the pipe immediately before the exec() call? There's a limitation here (still not sure if exec() succeeded), but at least you'd know for sure that the child got to that point without getting borked somewhere.

We solely want to know if the child is in middle of a new app or is attempting to exec the new app.

Sending a message before doesn't help

Ok, have an idea here. If you use the parent process to exec() instead of the child, then you can pass the PID of the child to the new exec'd process as an argument. If you've set up a signal handler in the child (or earlier), you can then pass a signal to the child process. Would that work here?

Where did you come up with an exec*() which takes a pid_t? And I still don't see where this logic is headed.


In other news, I found this vfork() function which might help. Although I'm not sure how it handles file descriptors.

[odditude]

I'll take that as an "I'm completely off here"

Anyway, I wasn't suggesting you pass exec() a pid_t. When you call exec, you can pass arguments to the target image. The idea here is to have the target image have one of its optional arguments be of type pid_t, which is how it can be passed the PID of the original process. Once it has the original process's PID, it can pass a signal through conventional means. The pid_t might need to be converted to a string since arguments are supposed to be char[], but it should still work since, at least for GNU C, pid_t is just int.

It might be simpler if I put it this way -

Parent calls fork(), whose return value is the child process. We're going to work backwards here and use the child process to continue on with main execution, and use the parent to actually exec the new app. The new app takes as one of its arguments a pid_t, which the parent gives as the child's PID. Now, you've got a "child" process which is continuing on in the original app, while the "parent" is actually a new app which has the PID of the original and can pass a signal to it.

Hopefully my logic's a little clearer now.

[Nach]

If I understand your logic, you need to modify the app that is being executed, which is not an option.

[DataPath]

If you can figure out how to prevent unhandled signals from terminating a process, you can send some arbitrary signal that your forked process handles, but the program you're exec()ing does not.

[Nach]

Done!

Okay code is in zsnes/src/linux/safelib.c
I basically reimplemented popen() to work around an issue we were having with the built in one.

I'd appreciate it if knowledgeable people would review it and see if they can spot errors.

I'd also appreciate if the various BSD users tested it, as I only tested on Linux.