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