This is the mail archive of the
cygwin-patches@cygwin.com
mailing list for the Cygwin project.
RE: Fix dup for /dev/dsp
- From: "Pierre A. Humblet" <pierre at phumblet dot no-ip dot org>
- To: "Gerd dot Spalink at t-online dot de" <Gerd dot Spalink at t-online dot de>,cygwin-patches at cygwin dot com
- Date: Mon, 26 Jul 2004 21:33:10 -0400
- Subject: RE: Fix dup for /dev/dsp
- References: <01C47174.AD674DB0.Gerd.Spalink@t-online.de>
At 12:04 PM 7/24/2004 -0400, Pierre A. Humblet wrote:
<snip>
>But the current code seems to assume a shared memory. Otherwise setting
>the "owner" to the current PID is completely useless (except perhaps
>if a fork occurs while the device is playing. Doing that would be
>an interesting test!) My 2 cents are that I would try to remove owner.
>While doing so we would see if (and why) it's helpful after all.
Gerd, (sorry for previous misspells)
Following up on one of my earlier questions, I have looked at the possible
"states" of the /dev/dsp driver and what would happen following a fork.
There are basically 3 states:
1) /dev/dsp just opened
- R/W flag set
2) After 1st write/read
- Audio_X_ exists
- Windows audio driver opened
- handle audio::dev_ != NULL
- audio::owner == PID
3) After reset/stop
- Audio_X_ exists
- Windows audio driver closed
- handle audio_X::dev_ keeps its old value
- audio_X::owner == 0
from here go back to 2 or close.
If a fork occurs in state 2), the "owner" will be set to the
PPID in the child. The child will remain locked out.
Suggestions:
- get rid of owner and related tests.
- reset dev_ to 0 when closing Windows driver
- use dev_ to determine what calls can be made to
the Windows driver
- reset dev_ to 0 in fixup-after-fork
Pierre