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

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

[Britton]

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."

Re: close()ing audio device always yields 'Interrupted system call'

[Dave Mielke]

[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.

-- 
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: dave@mielke.cc | Canada  K2B 6G3   | if you're concerned about Hell.

Re: close()ing audio device always yields 'Interrupted system call'

[Britton]

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: dave@mielke.cc | Canada  K2B 6G3   | if you're concerned about Hell.

Britton