Quoting Wan-Teh Chang (2016-12-09 18:54:47)
> This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0.
>
> In ff_thread_report_progress(), the fast code path can load
> progress[field] with the relaxed memory order, and the slow code path
> can store progress[field] with the release memory
On Fri, Dec 9, 2016 at 10:22 AM, Sean McGovern wrote:
> Hi Wan-Teh,
>
[...]
> Does this by any chance fix https://bugzilla.libav.org/show_bug.cgi?id=930 ?
Hi Sean,
No. My patch is completely unrelated to that bug.
That bug is a crash caused by a null pointer dereference.
Hi Wan-Teh,
On Dec 9, 2016 12:55, "Wan-Teh Chang" wrote:
This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0.
In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field]
Hi Luca,
I will update the patch with the longer description.
On Wed, Dec 7, 2016 at 5:42 PM, Luca Barbato wrote:
>
> Assuming it is not causing noticeable slowdowns/speedups (a benchmark
> would be welcome), I'm all for consistency.
I assume that initializing progress[0]
On 30/11/2016 23:13, Wan-Teh Chang wrote:
> This patch is intended to avoid confusion when one inspects the source code.
>
> ff_thread_report_progress() and ff_thread_await_progress() form a
> pair. ff_thread_await_progress() reads progress[field] with the
> "acquire" memory order (in the fast
Hi Anton,
On Wed, Nov 30, 2016 at 1:03 PM, Anton Khirnov wrote:
>
> Did you see any measurable change in performance after this patch?
This patch is intended to avoid confusion when one inspects the source code.
ff_thread_report_progress() and ff_thread_await_progress() form
Quoting Wan-Teh Chang (2016-11-30 21:33:37)
> This improves commit 59c70227405c214b29971e6272f3a3ff6fcce3d0.
>
> In ff_thread_report_progress(), the fast code path can load
> progress[field] with the relaxed memory order, and the slow code path
> can store progress[field] with the release memory