[vlc-devel] [PATCH] Handle GET_PARAMETER keepalive responses during PAUSE

[Paul Clark]

On 25/06/15 16:39, Ross Finlayson wrote:
>> , or (as your FAQ suggests) does everything have to go through a 
>> triggered event, in which the handler (which presumably we have to 
>> write?) calls sendXxx() in the doEventLoop() thread?  If the latter 
>> that adds a shedload of complexity - there are 7 different sendXxx() 
>> calls in 20-odd places, and we would only have a (void *) to pass 
>> parameters with…
>
> Well, that’s why C/C++ has these language types called ‘struct’s, in 
> which you can put as many parameters as you wish :-)

Haha, yes, that is of course what I meant :-)

So, to check my understanding and to document for anyone who ever feels 
brave enough to do this...

For each X:{OPTIONS, DESCRIBE, SETUP, PLAY, PAUSE, GET_PARAMETER, 
TEARDOWN}, we would need to:

a) Define a struct live_X_parameter_t
b) Register an event SendXEvent with a handler which calls the relevant 
sendX() method and signals back to the application thread any result, or 
at least that it's done (using shared variables and a condition in the 
parameter struct, I guess)
c) Allocate and fill a parameter struct
d) call TriggerEvent(SendXEvent) with it
e) Block waiting for the 'done' signal
f) Free the parameter struct

Then we'd need a new thread calling doEventLoop(), with a watch variable 
only set for shutdown.  As you pointed out before, the GET_PARAMETER 
keepalives could be done as a scheduleDelayedTask(), so that would save 
one in exchange...

Because as Felix points out there can be multiple active RTSP streams, 
we'd need a mechanism to share the UsageEnvironment and TaskScheduler 
between them (static pointers with a reference count?).  I assume 
TriggerEvent is thread safe for multiple caller threads?

So pretty complex stuff - but it's bulk code kind of complexity rather 
than lying-awake-at-night-worrying-about-thread-safety type of 
complexity, so I can see the benefit...

Best regards

Paul