Tue, Feb 21, 2023 at 10:47:28AM +0100, Klaus Schmidinger wrote:
On 19.02.23 18:29, Patrick Lerda wrote:
...
I had definitively a few crashes related to this class. Thread safety
issues are often not easily reproducible. Is your environment 100%
reliable?
My VDR runs for weeks, even months
On 19.02.23 18:29, Patrick Lerda wrote:
...
I had definitively a few crashes related to this class. Thread safety issues
are often not easily reproducible. Is your environment 100% reliable?
My VDR runs for weeks, even months 24/7 without problems.
I only restart it when I have a new version.
On 15/02/2023 16:51, Klaus Schmidinger wrote:
On 09.02.23 23:31, Patrick Lerda wrote:
...
This is really related to the C++ thread safety model, the patch below
fixes the main cRingBufferLinear issue:
diff --git a/ringbuffer.h b/ringbuffer.h
index 746fc51..a3fa499 100644
--- a/ringbuffer.h
On 09.02.23 23:31, Patrick Lerda wrote:
...
This is really related to the C++ thread safety model, the patch below fixes
the main cRingBufferLinear issue:
diff --git a/ringbuffer.h b/ringbuffer.h
index 746fc51..a3fa499 100644
--- a/ringbuffer.h
+++ b/ringbuffer.h
@@ -10,6 +10,7 @@
#ifndef
On 07/02/2023 07:59, Marko Mäkelä wrote:
Tue, Feb 07, 2023 at 12:54:16AM +0100, Udo Richter wrote:
Two-ended buffers are pretty good when used correctly, but nowadays
they have a small chance of triggering memory ordering issues, where
it is possible that written data to the buffer is still
Tue, Feb 07, 2023 at 12:54:16AM +0100, Udo Richter wrote:
Two-ended buffers are pretty good when used correctly, but nowadays
they have a small chance of triggering memory ordering issues, where it
is possible that written data to the buffer is still stuck in a distant
cache, while the updated
On 06.02.23 23:29, Klaus Schmidinger wrote:
It is supposed to be shared by *exactly* two threads.
One only writing 'head', the other only writing 'tail'.
Two-ended buffers are pretty good when used correctly, but nowadays they
have a small chance of triggering memory ordering issues, where it
On 06.02.23 21:11, Patrick Lerda wrote:
On 03/02/2023 10:36, Klaus Schmidinger wrote:
On 02.02.23 23:47, patrick9...@free.fr wrote:
On 02/02/2023 23:27, Klaus Schmidinger wrote:
On 02.02.23 23:16, Patrick Lerda wrote:
Beside preventing crashes with vdr-2.6.3 this is required to
get vdr to
On 03/02/2023 10:36, Klaus Schmidinger wrote:
On 02.02.23 23:47, patrick9...@free.fr wrote:
On 02/02/2023 23:27, Klaus Schmidinger wrote:
On 02.02.23 23:16, Patrick Lerda wrote:
Beside preventing crashes with vdr-2.6.3 this is required to
get vdr to work properly with the gcc thread
On 02.02.23 23:47, patrick9...@free.fr wrote:
On 02/02/2023 23:27, Klaus Schmidinger wrote:
On 02.02.23 23:16, Patrick Lerda wrote:
Beside preventing crashes with vdr-2.6.3 this is required to
get vdr to work properly with the gcc thread sanitizer.
cRingBufferLinear was designed to be thread
On 02/02/2023 23:27, Klaus Schmidinger wrote:
On 02.02.23 23:16, Patrick Lerda wrote:
Beside preventing crashes with vdr-2.6.3 this is required to
get vdr to work properly with the gcc thread sanitizer.
cRingBufferLinear was designed to be thread safe without locking.
What "crashes with
On 02.02.23 23:16, Patrick Lerda wrote:
Beside preventing crashes with vdr-2.6.3 this is required to
get vdr to work properly with the gcc thread sanitizer.
cRingBufferLinear was designed to be thread safe without locking.
What "crashes with vdr-2.6.3" are you referring to?
Klaus
Beside preventing crashes with vdr-2.6.3 this is required to
get vdr to work properly with the gcc thread sanitizer.
---
ringbuffer.c | 18 +-
ringbuffer.h | 3 +++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/ringbuffer.c b/ringbuffer.c
index 902c887..1c24df2
13 matches
Mail list logo
