[RFC] Reference counting on Audio objects for /dev/dsp

[Igor Pechtchanski]

On Sat, 17 Jul 2004, Igor Pechtchanski wrote:

> 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

Replying to myself - a sure sign of schitzophrenia... :-)

I'm wrong.  Some settings *are* kept in the fhandler objects (audiobits_,
audiofreq_, audiochannels_, and audioformat_).  So CGF is right -
archetypes will probably be the right solution here...  However, we still
need reference counting for the Audio objects, since even with archetypes
they'll be shared (unless you completely rewrite the code).
	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