Wolfgang Fritz wrote:
> Klaus Schmidinger wrote:
>
>>Stefan Huelswitt wrote:
>>
>>
>>>On 15 Mar 2005 Wolfgang Fritz <wolfgang.fritz@xxxxxxx> wrote:
>>>
>>>
>>>
>>>
>>>>Stefan Huelswitt wrote:
>>>>
>>>>
>>>>
>>>>>Ok, I changed the location, but I think that the real flaw is in
>>>>>VDRs player.h where the "player" var isn't checked before access.
>>>>
>>>>If tested this (temporarily inserted a test for player == 0 in
>>>>player.h), but it didn't help.
>>>>
>>>>maybe
>>>>
>>>>void cMP3Control::Stop(void)
>>>>{
>>>>delete player; player=0;
>>>>mgr->Halt();
>>>>mgr->Flush(); //XXX remove later
>>>>}
>>>>
>>>>has a concurrency problem? Who guarantees that no other thread
>>>>interrupts the mp3 thread while is in the destructor?
>>>>
>>>>Wouldn't be something like this a little bit safer:
>>>>
>>>>void cMP3Control::Stop(void)
>>>>{
>>>>cMP3player *p = player;
>>>>player = 0;
>>>>delete p;
>>>>mgr->Halt();
>>>>mgr->Flush(); //XXX remove later
>>>>}
>>>>
>>>>There seem to be more concurrency problems which crop up with the
>>>>graphlcd plugin. In rare cases I get a segfault when exiting a normal
>>>>vdr replay.
>>>
>>>
>>>Of course it's a concurrency problem.
>>>>From the fact that there is no mutex protection for the player
>>>var (neither in MP3 plugin nor in any other player code), I would
>>>guess that the cControl API was designed for accesses from the
>>>VDR foreground thread only (no concurrency problem in this case).
>>
>>
>>That's right - a player is not supposed to be accessed from anything
>>else than the foreground thread.
>>
>
>
> As far I can see, cControl::GetIndex() is the only method graphlcd calls
> in its own thread context to get periodic information about the replay
> progress (for updating its progress bar display). What would be the
> correct way to get that information?
>
> Wolfgang
I guess the correct way to do this would be to introduce a dedicated
function in cStatus. Just grabbing into the cControl from another
thread is not the right thing to do.
Klaus
