- goto set_timer_and_return;
- }
-
- // NOTE:
- // On my quest to solve the gs render hangups I am now
- // disabling the SIGHUP completely, and will do a wait
- // now and then instead. If the guess that xforms somehow
- // destroys something is true, this is likely (hopefully)
- // to solve the problem...at least I hope so. Lgb
-
- // ...Ok this seems to work...at least it does not make things
- // worse so far. However I still see gs processes that hangs.
- // I would really like to know _why_ they are hanging. Anyway
- // the solution without the SIGCHLD handler seems to be easier
- // to debug.
-
- // When attaching gdb to a a running gs that hangs it shows
- // that it is waiting for input(?) Is it possible for us to
- // provide that input somehow? Or figure what it is expecing
- // to read?
-
- // One solution is to, after some time, look if there are some
- // old gs processes still running and if there are: kill them
- // and re render.
-
- // Another solution is to provide the user an option to rerender
- // a picture. This would, for the picture in question, check if
- // there is a gs running for it, if so kill it, and start a new
- // rendering process.
-
- // these comments posted to lyx@via
- {
- int status = 1;
- int pid = waitpid(static_cast<pid_t>(0), &status, WNOHANG);
- if (pid == -1) // error find out what is wrong
- ; // ignore it for now.
- else if (pid > 0)
- sigchldhandler(pid, &status);