[FFmpeg-devel] [PATCH 2/2] avformat/udp: Replace use of pthread_cancel.
george at nsup.org
Sat Dec 3 15:35:22 EET 2016
Replying for the completeness of the discussion.
Le tridi 13 frimaire, an CCXXV, Matt Oliver a écrit :
> Thats the trick, not to large that it results noticeable shutdown delays to
> the user but not to quick that it polls to often, on a modern machine id
> think something like 0.01s would be ok.
I would agree. Unfortunately, even not speaking of the deep-sleep states
I evoked earlier, FFmpeg also supports much smaller hardware than what
is required to run anything related to MSVC. On some supported hardware,
a 100 Hz poll would be too much.
> I was thinking of just using setsockopt to set a value for SO_RCVTIMEO only
> in circular_buffer_task_rx. That way recv will timeout at the specified
> interval which will then use the existing code that checks the recv return.
> In case of timeout that check will continue back to top of loop that will
> have the s->close_req check to terminate the thread if needed.
> something like:
Indeed, in theory that would work. I always forget about these options.
In my experience they do not work reliably, and I would argue against
their use in portable code. For example, starting there:
can you tell me the type of the arguments to SO_RCVTIMEO? I know Linux
man page tells us it is struct timeval, but that is not a portable
Also, these options are just a band aid to implement polling.
> Is anyone working on that as your right i definitely think an event system
> for all protocols is the best option. Its just that has a larger scope than
> i can handle so i was trying to get a simple shorter term fix for udp.
Working on it really, no, and not in the foreseeable future. But I have
some detailed ideas about how to proceed for when I will get to it. I
can share them if someone wants to do it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: Digital signature
More information about the ffmpeg-devel