Re: [xine-devel] Other sputext deadlock

[Michael R. <mr...@us...>]

Hi Frantisek, Hi all,

I think I found a nice solution for the libsputext deadlock for which we only 
have an ugly interim fix in CVS now. The patch is attached; could everyone, 
who uses libsputext more often (Frantisek?) please test it?

Here is a short walk-through of what it does:
* overlays are flushed together with the other output queues in
  _x_demux_flush_engine() (I think this has just been forgotten.)
* introduction of a new helper function for SPU decoders:
  _x_spu_decoder_sleep() (the comment in spu_decoder.h should explain it)
* its implementation in video_decoder.c: The function waits until
  a given time is reached, but does regularly check three things:
   a) do we need to renew the port ticket
   b) do we need to release the decoder thread so that the video decoder
      can take over (indicator: video out is sending us decoder flushes,
      because it waits for the next frame)
   c) do we need to release the decoder thread so that the demuxer gets
      a free buffer and can continue from buffer_pool_alloc()
      (indicator: demux_action_pending)
* libsputext now uses this sleep function

Result: The sputext decoder should behave gracefully, no matter if it shares 
the thread with a video decoder or not.

Any comments from the fellow engine experts? Miguel, are you here? :)

> PS: Once I accidentally add just a subtitle file into playlist. It would
> take too much work to get play subtitle alone. :-) But there is deadlock
> after pressing STOP...

I think this should work now. If not: backtrace, please! ;)

Michael

-- 
panic("esp_handle: current_SC == penguin within interrupt!");
	2.2.16 /usr/src/linux/drivers/scsi/esp.c