Re: [PATCH] Free OSS device on pause
Chris Pitchford <[email protected]> Sun, 15 Oct 2006 17:06:24 +0100 (BST)
| Newsgroups | gmane.comp.multimedia.xmms.devel |
|---|---|
| Message-ID | <[email protected]> |
Ok, here's a quick run down of the problem
Consider the following functions and definitions:
int sound_fd;
int other_fd;
void play_then_pause() {
sound_fd=open("/dev/dsp",O_WRONLY);
play_something(sound_fd);
/* YOU ADDED: */
close (sound_fd);
{
void unpause_then_play_something() {
close(sound_fd);
sound_fd=open("/dev/dsp",O_WRONLY);
play_something(sound_fd);
close (sound_fd);
}
Here's the running program:
play_then_pause();
/* sound_fd now equals 3 (for example) since 3 was the next free FD when
play_then_pause was called.
FD 3 is now CLOSED since play_then_pause closed sound_fd */
other_fd=open("/data/file.mp3",O_RDONLY);
/* other_fd points to a NEW open file. Since FD 3 was closed in
play_then_pause it is now free for reallocation. Since open_fd was the
next open, it is now equal to 3. Just because sound_fd==3 doesn't stop
open returning 3
DO YOU SEE: other_fd==3 and sound_fd==3
Just because sound_fd is an integer makes NO difference to further
opens. an FD is just a NUMBER. Just because x=3 makes no difference to
anything.
Once an FD is closed, it can immediately be reallocated by an open.
*/
unpause_then_play_something();
/* The first thing unpause_then_play_something does is CLOSE sound_fd.
Since sound_fd is STILL equal to 3, it will close the FD that is
associated with the open MP3 file. This is bad, wrong, and definately a
bug.
It is never safe to double close an open FD. (or atleast not like this)
*/
To summerise. If something calls open between pausing and un pausing, it
is possible that the file descriptor will be reallocated. When unpause is
called, it will CLOSE that open filedescriptor that is NOT associated with
the FD.
FD's are allocated as first availble, more or less. They are not allocated
as What you used last time.
You're comment about and FD 300 being open is unlikely, Unless dup or dup2
are called to change the number of an FD 300 file descriptors being open
are unlikely
> Yes, that is true the the fd-number will/can be reused or change. Still
>
> 1) fd is a static in audio.c and thusly never used by any code
> outside, nor is it copied to the outside
fd is an int. It has actually very little to do with the filedecriptor.
There is nothing to stop something else closing and reopening. A collision
is likely
> 2) fd is only used *once* in a call-by-value context (write_all()) and
> that's no problem there as it is a plain and simple function
> and as such it is no problem if the fd gets a 3 or a 100 or is reused
> or changes due the execution of xmms.
It is if it gets reused between pause and unpause that the problem lies.
You are not closing an FD that you can guarantee belongs to you.
this really is 'file descriptors-101'
I hope this clears some of it up. I must say, releasing the FD on pause is
a really useful feature though, so keep up looking at it! I still use OSS!