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: [RFC] Reference counting on Audio objects for /dev/dsp


The current proposal will not work if someone first dups the device descriptor,
and then changes the audio settings with ioctl calls using one of the two
device descriptors. The other one will keep the old settings.

The patch I am preparing will fix this. However, I also have problems to build
the cygwin DLL. I'll try to do it tonight.

Gerd

On Friday, July 16, 2004 4:31 AM, Christopher Faylor [SMTP:cgf-no-personal-reply-please@cygwin.com] wrote:
> On Thu, Jul 15, 2004 at 04:28:56PM -0400, Igor Pechtchanski wrote:
> >On Thu, 15 Jul 2004, Christopher Faylor wrote:
> >
> >> On Thu, Jul 15, 2004 at 02:57:17PM -0400, Igor Pechtchanski wrote:
> >> >> 2) The other problem is that I find it sort of odd to see the dec()
> >> >> method performing a deletion.  Couldn't this be handled where, IMO,
> >> >> it should logically be handled, in the close function, e.g.,
> >> >>
> >> >>   if (!audio_out_->dec ())
> >> >>     delete audio_out_;
> >> >> ?
> >> >
> >> >Umm, that's actually a rather standard construct in reference counting
> >> >(called "object suicide" -- you should get some references if you Google
> >> >for "object suicide reference counting").
> >>
> >> Yes, I thought that would be your answer, however, I don't like the idea
> >> of having a method called "inc" which just increments a count and a method
> >> called "dec" which decrements a count and, oh, hey, it might delete the
> >> object, too.
> >>
> >> It seems more straightforward to delete audio_out_ in the place where
> >> you'd expect it to be deleted rather than having a "dec" call which,
> >> if you check, you'll notice that it deletes the buffer.
> >>
> >> Or, as a compromise, don't call it 'dec'.  Call it something which
> >> illustrates what it is doing.
> >
> >Right.  I think the compromise is good -- I was thinking of maybe using
> >registerReference() and releaseReference() (or deregister?).  We could
> >shorten them by removing "Reference" from the names, too.  In any case,
> >I'd wait for Gerd's input before deciding on the specific code to go in.
> 
> That sounds good to me.
> 
> Now we just need Gerd's ok.
> 
> cgf


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