Hi Guys, do we have any further news?
Corinna On Jul 26 21:33, Pierre A. Humblet wrote: > 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 -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Co-Project Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.