[MPlayer-dev-eng] [PATCH] Non-blocking mp_msg

[Paul Pedaal]

---
Saatja: Maciej Paszta <paszczi at go2.pl>
Kuupäev: 09.06.2005 13:43:08
---
> On Tuesday 07 June 2005 18:01, Paul Pedaal wrote:
> > +int nbfflush(FILE* stream){
> > +    struct pollfd* fds;
> > +
> > +    fds[0].fd = fileno(stream);
> > +    fds[0].events = POLLWRNORM;
> > +    poll(fds, 1, 0);
> > +    if (fds[0].revents && POLLWRNORM) {
> > +         fflush(stream);
> 
> fds[0].revents holds the events that actually occured (requested by
> the
> fds[0].events or other diagnostic/error values), so if we want to
> check if
> revents holds our POLLWRNORM it should go like this:
> 
> if (fds[0].revents & POLLWRNORM)
> 


Oops.. A very bad typo :(


---
Saatja: Alexander Strasser <eclipse7 at gmx.net>
Kuupäev: 09.06.2005 11:14:32
---
>   I am not sure if we really need this at all.
> But at least it may have portability issues i guess...

The most annoying is using mplayer with screen. When screen displays one if its own messages it blocks the stdout for the program in the current window. You will get  a freezed mplayer every time screen thinks there is something to tell you :(

poll() should exist on any OS that offers SysV system calls. select() can be used on Berkley-compatible systems.
This is something that can be checked for in the configure script. My little patch (and my skills) don't have that unfortunately :( I just wrote it to make mplayer behave better in screen.