This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Fix dup for /dev/dsp


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]