Le tridi 13 frimaire, an CCXXV, Matt Oliver a écrit : > I was just writing an email to rephrase but you beet me to it (sorry i > wasnt faster)
No problem. > I should rephrase this to "Why is polling with an acceptable timeout/sleep > not acceptable". Obviously a event based callback would be more efficient > but wouldnt setting an appropriate recv timeout then checking for thread > exit before looping the recv call be an acceptable compromise. The thread > exit check is minimal and if not set it would just go back into the > blocking recv until data is received or the timeout triggers again. Long > term callbacks would be better but would this be acceptable short term. What would you consider an appropriate timeout, more precisely? First, I would like to remind you that you cannot block with a timeout, you would have to rework the code to use the ill-named poll(), which would bring it back to its state before the use of pthread_cancel(). You are right that it would take care of the latency problem of the network side, and allow a long timeout. But the latency is a problem too for the cancellation. We had a 3 seconds timeout, users did get impatient and interrupted it forcefully. Furthermore, the core of your argument is that "the thread exit check is minimal", but as I explained, it is not on embedded devices: anything except "block until the kernel wakes up" is too much because it prevents deep sleep states and drains the battery. Modern operating systems allow multi-peer applications to work in a completely poll-free completely notification-based way. FFmpeg, based on very old code without global design, is quite far from achieving that. But moving away from that is definitely moving in the wrong direction. I assume you are not working just on a general distaste about pthread_cancel(): you have in mind a specific platform in mind where it is not available and you need the UDP thread, have you not? Then I suggest working for that platform: find a way of implementing a poll-free delay-free interruption mechanism. Maybe using non-portable properties of the platform (like closing on another thread like Hendrik evoked) or an entirely different API. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
