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


On Sat, 17 Jul 2004, Gerd Spalink wrote:

> 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
>
> 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

Huh?  I'm most likely misunderstanding something...  Aren't the audio
settings kept in the Audio objects?  Those are shared, so any changes made
to one via the first descriptor should be visible via the second
descriptor, right?
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"I have since come to realize that being between your mentor and his route
to the bathroom is a major career booster."  -- Patrick Naughton


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