[MPlayer-dev-eng] [RFC] stream controls with cache

[Alban Bedel]

On Fri, 23 May 2008 19:22:35 +0200
Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:

> On Fri, May 23, 2008 at 07:33:46PM +0200, Alban Bedel wrote:
> > On Thu, 22 May 2008 12:24:16 +0200
> > Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> > > something is still behaving a bit weird, but in principle attached
> > > patch makes stream controls work through the cache (chapter
> > > seeking only so far).
> > > At least for cdda:// it works, though there is some code in the
> > > stream layer that prints the current track number which results
> > > in really ugly output...
> > > Do you think this is an acceptable way to do this?
> > 
> > I find it OK, but IMHO there is only 2 solution that can totally fix
> > this problem: add a non-blocking mode to the stream API or switch
> > the cache to use a thread.
> 
> For Windows the cache already uses a thread, but it probably has even
> more problems currently.

Yes, some control ops probably need a proper locking. It wouldn't be bad
to fix these (eventual) bugs.

> For Linux, a system that communicates via a pipe while being more
> effort could well be more reliable actually.

With IPC you have the problem of argument passing, currently the
control API can use any type. Obviously we could do a special case for
each control, but that's not very maintainable. Otherwise we have to
impose some restrictions, like no pointer and size less than SOME_MAX,
or use some special malloc() that take memory from the shared space.

And then there is the problem of timely responding to a control call.
Beside threads a solution could be too use signals to interrupt the
system calls, but I don't know if that behaviour is available
everywhere, and how well it work. Most stream would then probably need
a fix or two to handle EINTR properly.

> But I think someone already started implementing cache via posix
> threads, but it got stuck for some reason...

I don't think it would be really that hard, the only thing that can be
called concurrently is control(), and most control just read so I don't
expect much locking need.

But all in all I agree it would be best if we manage to stay away from
threads.

	Albeu