On 3 December 2016 at 05:17, Nicolas George <geo...@nsup.org> wrote: > Le duodi 12 frimaire, an CCXXV, Matt Oliver a écrit : > > Which changes would those be? > > The fix of errno / return value for pthread_cond_timedwait() for > example. >
That was because the pthread wrappers dont set errno, so its a required change to remove dependency on pthread. > > > This function is already set as nonblocking > > I think you read this specific part of the code wrong. Unfortunately, > since this is a pivotal part of your reasoning, it ruins everything > else. > 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 > > recv() can not be in non-blocking mode here because it would cause the > whole thread to behave in busy-wait, which is completely unacceptable. > Just out of curiosity why is polling considered unacceptable? > > Remember that pthread_cancel() was introduced here to eliminate polling. > Please do not bring it back. The way forward is to implement an event > loop for all protocols. 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. So isnt this just removing the polling from ffmpeg and adding it back in somewhere else anyway. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
