On 10/05/2012 09:25 AM, Diego Biurrun wrote:
On Fri, Oct 05, 2012 at 02:48:20AM +0200, Luca Barbato wrote:
On 10/05/2012 01:29 AM, Ronald S. Bultje wrote:
On Thu, Oct 4, 2012 at 4:27 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
Oh right you mean for performance?
Hi,
On Fri, Oct 5, 2012 at 12:25 AM, Diego Biurrun di...@biurrun.de wrote:
On Fri, Oct 05, 2012 at 02:48:20AM +0200, Luca Barbato wrote:
On 10/05/2012 01:29 AM, Ronald S. Bultje wrote:
On Thu, Oct 4, 2012 at 4:27 PM, Ronald S. Bultje rsbul...@gmail.com
wrote:
Oh right you mean for
On 05/10/2012 11:47 AM, Ronald S. Bultje wrote:
One of the mailinglists recently had an email about our slice
threading impl relying on wakeups-only-by-signal, i.e. spurious
wakeups could lead to races, can you look at that and see if it fixes
it?
Perhaps this is related:
On 10/04/2012 01:46 AM, Luca Barbato wrote:
From: Ronald S. Bultje rsbul...@gmail.com
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
This bug was found using TSAN.
Signed-off-by: Luca Barbato
Hi,
On Thu, Oct 4, 2012 at 12:59 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 10/04/2012 01:46 AM, Luca Barbato wrote:
From: Ronald S. Bultje rsbul...@gmail.com
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to
On Thu, Oct 4, 2012 at 4:27 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
Hi,
On Thu, Oct 4, 2012 at 12:59 PM, Luca Barbato lu_z...@gentoo.org wrote:
On 10/04/2012 01:46 AM, Luca Barbato wrote:
From: Ronald S. Bultje rsbul...@gmail.com
The variable is copied to subsequent threads at the
On 10/05/2012 01:29 AM, Ronald S. Bultje wrote:
On Thu, Oct 4, 2012 at 4:27 PM, Ronald S. Bultje rsbul...@gmail.com wrote:
Oh right you mean for performance?
fate-h264-conformance-cama2_vtc_b
fate-h264-conformance-cama3_vtc_b
should be ok.
I'd push your patch + my style nits soon, I'll
From: Ronald S. Bultje rsbul...@gmail.com
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
---
libavcodec/h264_cabac.c | 41 -
libavcodec/h264_cavlc.c | 33
From: Ronald S. Bultje rsbul...@gmail.com
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
---
libavcodec/h264_cabac.c | 41 -
libavcodec/h264_cavlc.c | 33
From: Ronald S. Bultje rsbul...@gmail.com
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
This bug was found using TSAN.
---
libavcodec/h264_cabac.c | 41 -
From: Ronald S. Bultje rsbul...@gmail.com
The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.
This bug was found using TSAN.
Signed-off-by: Luca Barbato lu_z...@gentoo.org
---
Few cosmetic nits.
11 matches
Mail list logo