[vdr] [PATCH] mp3-0.9.11 signals end of replay too late

[Klaus Schmidinger]

Stefan Huelswitt wrote:
> On 15 Mar 2005 Wolfgang Fritz <wolfgang.fritz at gmx.net> 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.

Klaus

> If graphlcd is running on another thread, this could be the
> explanation...
> 
> Regards.
> 


-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls at cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________