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