Re: [Discuss-gnuradio] thread safety of gr_wavfile_sink::close()

----- Original Message -----
From: "Eric Blossom" <eb@comsec.com>
To: "Don Ward" <don2387ward@sprynet.com>
Cc: "gnuradio mailing list" <discuss-gnuradio@gnu.org>
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?

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio