Hi, Klaus Schmidinger wrote:
But this doesn't work for cDevice::AttachReceiver(). If a plugin needs to attach a receiver this is typically a different thread than those which created cDevice.Reinhard Nissl wrote:Actually 'Start()' should only be called from the thread that has created the cThreadHi, C.Y.M wrote:I've realized this too with vdr-xine and vdr-osdteletext. I've tracked this down to cThread::Start() where childTid is used to guarantee that only a single thread is started even if Start() is called multiple times.Anssi Hannula wrote:I also am positive I cleaned the src tree before building. Take a look at the log when vdr attempts to initialize a stream (when using the new threading). What is happening is that VDR is creating THREE receiver threads when it should only be creating ONE. If I go back to the previous threading model, only one receiver thread is initialized and everything is fine.Klaus Schmidinger wrote:Now, does anybody have any idea why these changes would cause all the described malfunctions in plugins? Is everybody who has encountered problems with plugins *ABSOLUTELY* *POSITIVELY* *ONEHUNDRED PERCENT* sure that they did make plugins-clean clean vdr plugins before running VDR with the modified thread.[hc]?Yes, I did.
But this test doesn't work anymore for 1.3.17 as the time is too long until the child thread sets this variable to a value <> 0.
I've already informed Klaus about this issue. Maybe an additional flag should be added that will be used for this test now in 1.3.17. And I think it would also be a good idea to synchronize calls to Start() from multiple threads.
class. Anything else could be considered a programming error.