[MPlayer-dev-eng] [PATCH] use pthreads for caching

[A Mennucc]

hi Uoti

Uoti Urpala ha scritto:
> On Fri, 2007-01-26 at 23:42 +0100, A Mennucc wrote:
>> My impression is this: after the fork, there are two signal handler
>> around; then there is a bug in the codec (or in the gmplayer GUI) that
>> triggers a signal from the Xlibs; but it gets caught in the wrong
>> signal handler; from there on , mayhem.
> 
> The forked process should be separate and there should be no way for a
> signal to be delivered "to either process" arbitrarily. The cache
> process shouldn't be running any Xlib code (if it is that's already
> broken). So I think this explanation for the problem is flawed or at
> least incomplete.


yes, I had quite a hard time debugging bug
http://bugs.debian.org/396962
and indeed I agree that my first explanation was probably flawed... it
was just "my impression"

here is another possible explanation

 ------------

I am debugging
$ gdb gmplayer http://robots.stanford.edu/movies/sca80a0.avi

put a break in line 120, in stream/tcp.c , at the command 	

  if(verb)
mp_msg(MSGT_NETWORK,MSGL_STATUS,MSGTR_MPDEMUX_NW_ResolvingHostForAF,
host, af2String(af));

that outputs the line
  Couldn't resolve name for AF_INET6: robots.stanford.edu
and opens a window dialog to display the same line

but then this is called again inside the caching code (and I do not
understand why... this is indeed a flaw), and again tries to display
  Resolving robots.stanford.edu for AF_INET6...
and open a dialog....

but! this time, the caching code is running in a separate process. Huge
problem! you can Google around and find that in GTK and Xlib it is very
dangerous to draw windows from two different forked processes. So the
whole windowing code goes haywire.

 ----

So the reason that my patch for threaded caching works is that it is
possible to open dialog windows from different threads.

possible solutions:

1) make sure you do not ever ever display a dialog from the caching code
2) use pthreads

I would suggest the 2nd  :-)
(as I explained in my other email, mplayer is already compiled to use
pthreads in linux)

a.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070127/a95e222e/attachment.pgp>