On Fri, Jun 21, 2002 at 12:01:28AM -0400, Havoc Pennington wrote:
Typically one handles this by setting the SIGPIPE action to SIG_IGN so that you get an EPIPE error instead of SIGPIPE.
Indeed, as another suggested and as did occur to me. I was wondering if something more generally useful to the library could be done than everybody dealing eith EPIPE and SIGPIPE though.
May be a race condition in that: if (flag) /* SIGCHLD can come here */ write_to_child ();
This can be true. However in my case, it's:
signal(SIGCHLD, child_reaper);
g_spawn_async_with_pipes(...);
write_to_child();
Because signal handlers are effectively global variables, we try to avoid setting them up in libraries - they are reserved for application use.
Yeah, that did occur to me too. I thought perhaps before setting up the handler, if there was one already, the g_spawn_*() handler would deal with the SIGCHLD first and if the pid exiting was not in it's table of pids to watch for, cascade on to the user's installed handler. Hmmmm. I don't think that is actually doable without wasting the wait() from the user's handler. But if each pid being waited for by g_spawn_*() were tested with a waitpid/WNOHANG you should be able to avoid wait()ing for children other than g_spawn_*()'s. It was a thought anyway but your opinion on signal handlers in libraries is respected.
I think you normally get a G_IO_HUP condition on the file descriptor when the other end closes, or you get read() returning immediately with no data.
I can look into that too.
Another thing you can do to check if the child is running is to waitpid() with WNOHANG, to do that you have to run with G_SPAWN_DO_NOT_REAP_CHILD.
Indeed. It's just so much nicer having a callback to do cleanup when the child exits rather than have to poll for that status on each write_to_child(). Thanx for all of the input though. Much appreciated. b. -- Brian J. Murrell
Attachment:
pgpF7ek3PSugr.pgp
Description: PGP signature