On Fri, Apr 30, 2010 at 08:48:48PM -0400, Don Ward wrote: > > ----- Original Message ----- From: "Eric Blossom" <[email protected]> > To: "Don Ward" <[email protected]> > Cc: "gnuradio mailing list" <[email protected]> > Sent: Friday, April 30, 2010 8:25 PM > Subject: Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close() > > > >On Fri, Apr 30, 2010 at 07:42:32PM -0400, Don Ward wrote: > >>I have a question about the thread safety of > >>gr_wavfile_sink::close(). The description says it is thread safe > >>and it uses d_mutex, but what is to stop the work() function from > >>writing the file at the same time that close() (via close_wav()) is > >>writing and closing the file? gr_wavfile_sink::work() does not lock > >>d_mutex (except when d_updated is set). Is there something going on > >>behind the scenes to prevent the threads from mangling the output > >>file, or is this a problem with the code? > >> > >>The reason I am interested is because I would like to do something > >>similar with gr_udp_sink, allowing one socket to be closed and a new > >>one to be created when one client finishes and another client starts > >>up. > >> > >>Thanks, > >> > >>-- Don W. > > > >It looks fairly hosed up. One fundamental design/documentation > >problem is that the header file does not document which variables must > >be protected by the mutex. Also, proper use of the mutex (including > >in work) would eliminate all of the code related to d_updated. > > So, it is ok to use the mutex across the work function?
Yes, as long as nobody who's holding it ever blocks. > >While I'm at it, set_bits_per_sample quietly fails for any value not > >equal to 8 or 16. > > > >gr_udp_sink has similar problems. > > Ok. Let me work on gr_udp_sink, then you can tell me how close I > came to getting it right. > > -- Don W. Thanks! Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
