close()ing audio device always yields 'Interrupted system call' why?

Even if I SYNC or RESET the device before closing. The program I am working on always writes the correct amount of data to it's data file, and never moves less than a full (possibly dual channel) sample of data at a time. This return value doesn't appear to be documented in the close() man page. Anyone have any idea what might be causing this?

I am running 2.2.14.

Britton Kerin
__
GNU GPL: "The Source will be with you... always."

[quoted lines by Britton on April 1, 2000, at 17:08]

The close() is taking a significant amount of time, and your program is receiving a signal during that interval.

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.

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.

Britton