On Sat, 1 Apr 2000, Dave Mielke wrote: > [quoted lines by Britton on April 1, 2000, at 17:08] > > >Even if I SYNC or RESET the device before closing. > > The close() is taking a significant amount of time, and your program is > receiving a signal during that interval. This is apparently exactly what was happening Dave, thanks for your help. The guilty(?) signal turns out to be SIGCHLD, and looks like being due to the manager thread going zombie. The odd thing is that both the threads finish, and return success codes, and have apparently done their jobs correctly, but the problem still comes up when I try to close /dev/dsp, even if I sleep() for a while before trying the close(). Is it expected behavior for the kernel to bother the parent process with signals regarding thread child process states, even after successful pthread_join()s, or is this suspicious behavior on the part of the kernel or thread library? Why should I get this signal at the exact point where I call close(audio_fd)? I thought I would ask here before pestering the kernel people, any advice greatly appreciated, and thanks again for your help. > -- > Dave Mielke | 856 Grenon Avenue | I believe that the Bible is the > Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me > EMail: [EMAIL PROTECTED] | Canada K2B 6G3 | if you're concerned about Hell. Britton
