There are lots of forks when launching esound. When this doesn't work (no
/dev/dsp) the reaper will add stuff in the pipe because it receives SIGCHLD.
The problem is that it is not read by vte_reaper_emit_signal() because the g-s-d
process is still in another part of the code. So we fill the pipe. And we block.
I think we should do something like this in vte_reaper_init():
fcntl (reaper->iopipe[1], F_SETFL, O_NONBLOCK);
According to some doc:
A write request for {PIPE_BUF} or fewer bytes will have the following effect: If
there is sufficient space available in the pipe, write() will transfer all the
data and return the number of bytes requested. Otherwise, write() will transfer
no data and return -1 with errno set to [EAGAIN].
So the write won't block and no data will be written. This won't break anything.
Hope I'm not wrong.
(btw, having a reaper just for the typing monitor is really a bad idea. The
long-term solution would be to remove the reaper if possible.)
Ok, I think I'm understanding the problem.
There are lots of forks when launching esound. When this doesn't work (no emit_signal( ) because the g-s-d
/dev/dsp) the reaper will add stuff in the pipe because it receives SIGCHLD.
The problem is that it is not read by vte_reaper_
process is still in another part of the code. So we fill the pipe. And we block.
I think we should do something like this in vte_reaper_init():
fcntl (reaper->iopipe[1], F_SETFL, O_NONBLOCK);
According to some doc:
A write request for {PIPE_BUF} or fewer bytes will have the following effect: If
there is sufficient space available in the pipe, write() will transfer all the
data and return the number of bytes requested. Otherwise, write() will transfer
no data and return -1 with errno set to [EAGAIN].
So the write won't block and no data will be written. This won't break anything.
Hope I'm not wrong.
(btw, having a reaper just for the typing monitor is really a bad idea. The
long-term solution would be to remove the reaper if possible.)