> On Jun 20, 2023, at 8:39 AM, Hansen Jan Rørgård
> wrote:
>
> Thanks for the clarification regarding the intended behaviour of
> triggerEvent() ie. no queueing.
>
> Also thanks for the update to fix the race condition. As
> std::atomic_flag::test() is a C++20 feature the compiler has to be
using, copying
or
disseminating it or information in it. Please notify the above if any
misdirection.
-Original Message-
From: live-devel On Behalf Of Ross Finlayson
Sent: 16. juni 2023 16:03
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] [EXTERNAL] Re: Poss
One more thing...
> On Jun 7, 2023, at 5:52 AM, Hansen Jan Rørgård
> wrote:
>
> triggerEvent called twice but eventHandler is called once:
> ===
> Let's say NT has called createEventTrigger with EH1 and now has:
> ET1 : EventTriggerId1
> Then we can h
I have now installed a new version (2016.06.16) of the “LIVE555 Streaming
Media” code that changes (in the “BasicTaskScheduler” class) the implementation
of “triggerEvent()”.
The solution was a little different to that which I outlined in my previous
message on this thread. The definition of “
OK, the problem here is how we have (tried to) protect access to the
“fTriggersAwaitingHandling” variable, in order to make it safely accessible
(writeable) by a non-LIVE555 thread. To date, we have declared this variable
as “volatile”, but that isn’t the proper mechanism for inter-thread
comm
Hi,
Here is more information about the issue and an attached test program that is
able to reproduce the issue(s).
First let's define:
LT : LIVE555 thread
NT : non-LIVE555 thread
EH1 : EventHandler1
EH2 : EventHandler2
TAW : fTriggersAwaitingHandling
triggerEvent called but eventHandler is not:
