Le tridi 13 frimaire, an CCXXV, Matt Oliver a écrit : > That was because the pthread wrappers dont set errno, so its a required > change to remove dependency on pthread.
The pthread wrappers are supposed to match the pthread API, and it does not use errno: this change is needed by itself. > Your right i misread the use of ff_socket_nonblock so an extra change would > need to be added to set that to nonblocking instead. Theres already code > after the recv call that checks if any data was read back and just loops if > there wasnt any available which implements polling (should it be in > nonblocking mode). So thats why i assumed nonblocking was acceptable Looping is necessary in case of interrupted system calls; the code is overly careful by testing EAGAIN too. > Just out of curiosity why is polling considered unacceptable? It is awfully inefficient. If the polling interval is large, it adds latency to the processing. If it is short, it becomes a resource drain. Multimedia application often require low latency. You may think that a 100 Hz polling will have low latency enough for most uses and still be a negligible power drain, and thinking about PC applications you would probably be right. But think of a player on an embedded device reading a network stream that got interrupted. Since it is no longer playing, you do not pay attention to it, and you do not realize the player is still there, polling the network to see if it comes back. As a consequence, the CPU cannot enter deep-sleep state, and your battery in drained in a few hours. And of course, if someone were to just turn the socket non-blocking, since the loop does not have a timer in it, it becomes the ultimate form of polling evil: busy wait, and this is a terrible power drain even on huge PCs. FFmpeg uses polling all over the place, but fortunately, with just the UDP streams it can be entirely avoided. Eliminating all polling is amongst my long-term projects. > As i understand it pthread_cancel implements polling internally anyway as > any blocking function performed in the rx thread has to periodically check > the status of pthread_cancel to see if it has been set from another thread. I believe you are wrong. The core property of pthread_cancel(), which you can not emulate portably with other functions, is that it interrupts blocking system calls like recv(). It is implemented internally with non-portable notification techniques: a specific signal on Linux if I read correctly. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
