[vdr] [ANNOUNCE] VDR developer version 1.7.20
vdr-l at jelal.kn-bremen.de
Sat Aug 20 13:57:47 CEST 2011
On Sat, Aug 20, 2011 at 12:16:01PM +0200, Klaus Schmidinger wrote:
> On 19.08.2011 20:48, Udo Richter wrote:
> > Am 16.08.2011 23:13, schrieb Klaus Schmidinger:
> >> On 16.08.2011 19:56, Udo Richter wrote:
> >>> Am 16.08.2011 18:57, schrieb Klaus Schmidinger:
> >>>> - cSkins::Message() now blocks calls from background threads (thanks to
> >>>> Michael Eiler for reporting a crash in such a scenario).
> >>> Unfortunately, this will break the osdserver-plugin, that does call
> >>> these directly from the network interface thread - though not without
> >>> first locking the main thread in a safe state.
> >>> I'll see if I can work around this, or if I can come up with some other
> >>> solution.
> >> Actually cSkins::QueueMessage() is supposed to be used for issuing
> >> messages from a background thread.
> > Sure, however QueueMessage does not wait and does not return an user key
> > press.
> That's by design ;-)
> A background thread is not supposed to do this!
> > Osdserver exports all of the message functions, including
> > QueueMessage.
> Well, I guess it shouldn't.
> > I'll probably solve this by a main thread callback, some other parts of
> > OsdServer do this already.
> > A solution / extension on VDR side would be to replace the 'main thread'
> > concept with a 'big VDR lock': A global lock that the main thread
> > releases just before sleeping, and re-locks after waking up. That way,
> > any background thread could use that lock to trap the main thread
> > safely, and use all of the not thread safe parts of VDR that previously
> > were only safely available to the main thread.
> > I think the kernel guys have a big lock they don't use any more, maybe
> > we can get that one. ;)
> The kernel developers only recently got rid of this, and they had good
> reasons to do so, I guess. I wouldn't want to do that in VDR.
The general reason kernels get a big (or "giant") lock is when
adding smp support (more than one cpu, i.e. more than one thread
can be running at a time so suddenly there's need for locking in a
lot more places.) The reason that big lock is removed later (actually
pushed out to different individual locks) is only to improve smp
performance (less time spent waiting on a single lock), which I
guess an userland app like vdr would have less reason to worry
Just thought I'd mention... :)
More information about the vdr