Hello,
I want to create a plugin which informs other applications about vdr status changes. This is no problem for start/stop of recording and replaying. But I want also detect other status changes without "polling" the vdr structures.
Now my questions/wishes:
- It would be nice to extend the cStatus class with some more events (such as adding, removing or changing timers or channels, change of the next active timer, disk full warnings, deletion of recordings).
- Plugins can iterate on timer and channel lists. But I think, this lists are not thread safe for concurrent iterating and modifying by vdr and plugins with own threads.
Klaus - how do you think about this?
Greetings, Bernd
Bernd Juraschek wrote:
Hello,
I want to create a plugin which informs other applications about vdr status changes. This is no problem for start/stop of recording and replaying. But I want also detect other status changes without "polling" the vdr structures.
Now my questions/wishes:
- It would be nice to extend the cStatus class with some more events (such as adding, removing or changing timers or channels,
This could be detected by watching the timestamps of channels.conf and timers.conf.
change of the next active timer,
Just use SVDRP NEXT.
disk full warnings,
Any application can check the disk usage directly.
deletion of recordings).
Why would an external application need to know that?
- Plugins can iterate on timer and channel lists. But I think, this lists are not thread safe for concurrent iterating and modifying by vdr and plugins with own threads.
You're right, they're not thread safe. But since you wrote that you want to inform "other applications" about these things, and I have shown you ways how to do that (see above), I don't think these things are actually necessary in cStatus.
Klaus
On Wednesday 14 September 2005 18:09, Klaus Schmidinger wrote:
change of the next active timer,
Just use SVDRP NEXT.
Not very nice to have to connect to VDR via SVDRP within a plugin :)
- Plugins can iterate on timer and channel lists. But I think, this lists are not thread safe for concurrent iterating and modifying by vdr and plugins with own threads.
You're right, they're not thread safe. But since you wrote that you want to inform "other applications" about these things, and I have shown you ways how to do that (see above), I don't think these things are actually necessary in cStatus.
I've been stumbling over this recently, too. AFAIK the channels list is thread safe already, if the plugin calls Lock() and Unlock() on the Channels object properly. It would be nice if the other lists could receive these capabilities too :)
Greetings, Sascha Volkenandt
Sascha Volkenandt wrote:
On Wednesday 14 September 2005 18:09, Klaus Schmidinger wrote:
change of the next active timer,
Just use SVDRP NEXT.
Not very nice to have to connect to VDR via SVDRP within a plugin :)
I thought he wrote that he wanted to make that info available to _external_ programs. Inside VDR he can always call cTimers::GetNextActiveTimer().
- Plugins can iterate on timer and channel lists. But I think, this
lists are not thread safe for concurrent iterating and modifying by vdr and plugins with own threads.
You're right, they're not thread safe. But since you wrote that you want to inform "other applications" about these things, and I have shown you ways how to do that (see above), I don't think these things are actually necessary in cStatus.
I've been stumbling over this recently, too. AFAIK the channels list is thread safe already, if the plugin calls Lock() and Unlock() on the Channels object properly. It would be nice if the other lists could receive these capabilities too :)
Let's think about this after version 1.4.
I just _have_ to be increasingly restrictive with changes, or we'll never get anywhere near a stable 1.4 ;-)
Klaus
I've been stumbling over this recently, too. AFAIK the channels list is thread safe already, if the plugin calls Lock() and Unlock() on the Channels object properly. It would be nice if the other lists could receive these capabilities too :)
Locking is there for cChannels, but it is not safe to store a cChannel * pointer (may be deleted any time) nor a channel number (may be moved or deleted any time). The only safe way currently seems to be storing a channel ID. Although all this is not a practical problem for anyone now, it may well be one day so there should be some thought put into this.
I think when there is no time pressure (1.5 series) there should be a clear statement in the documentation of each class which global structures and objects are thread-safe to access and to store and which are main-thread only (OSD, cControl), and mechanisms to track changes. Think of creation, change and deletion of timers and channels, or hot-pluggable devices like those new DVB-T boxes which are plugged in and unplugged at any time.
Marcel
Let's think about this after version 1.4.
I just _have_ to be increasingly restrictive with changes, or we'll never get anywhere near a stable 1.4 ;-)
Klaus
-
Bernd Juraschek -
Klaus Schmidinger -
Marcel Wiesweg -
Sascha Volkenandt