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 about. Just thought I'd mention... :) Juergen _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
