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

[A Mennucc]

hi

Summary: to cache data, the code stream/cache2.c forks a subprocess
(on all archs but win32); while trying to debug some Debian bugs, I
have come to the conclusion that this does create some of the problems
I was seeing. So I attach a patch that uses pthreads instead.  Please
test it (I did not test the code for Windows against regressions).

 ----

Lets see in particular http://bugs.debian.org/396962

The problem here is that 
$ gmplayer  http://robots.stanford.edu/movies/sca80a0.avi
hangs.

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.

After applying my patch, gmplayer can play that AVI w/o problems.

 ----

a similar bug is triggered by http://sam.zoy.org/zzuf/lol-mplayer.avi

and again this patch somehow works around it

 ----

Another good effect of this patch is that it is easier to debug the
cache code. When I tried to debug the above bugs, I had to have two
gdb sessions; and I had quite a few problems (there is some bug in GDB
that crashes it when I try to attach to another process).  With my
patch, you just need to open one gdb session, and set breakpoints in
it, and that is all.


bye

a.

-- 
Andrea Mennucc

"The EULA sounds like it was written by a team of lawyers who want to tell 
me what I can't do, and the GPL sounds like it was written by a human 
being who wants me to know what I can do."
Anonymous,    http://www.securityfocus.com/columnists/420
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-stream-pthread.diff
Type: text/x-diff
Size: 6864 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070126/7fcaf715/attachment.diff>