[FFmpeg-devel] [PATCH] udp: do not wait for data from the receiving thread.
nicolas.george at normalesup.org
Thu Mar 15 10:21:46 CET 2012
Le quintidi 25 ventôse, an CCXX, Reimar Döffinger a écrit :
> Well, that was the case originally. But if I remember correctly some
> people decided that it shouldn't be necessary in the first place
> and changed lower level code to be blocking.
I do not remember that discussion. The receive thread for UDP comes from our
side: it was added by the following commit in May last year:
udp: add a thread into udp.c for receiving data into a circular buffer
which initially did not support non-blocking at all; non-blocking was added
by Michael in December:
udp: support non blocking reads with fifo
but he was unaware of the current design of non-blocking and interrupting.
Apart from that, our retry_transfer_wrapper and udp_read are almost
identical to the ones on the libav side.
Furthermore, the TCP code also still behaves like that.
So if anyone has spoken about changing that design, no one has acted upon
OTOH, while re-reading the code, I realized that udp_read (and tcp_read)
introduce a 100 ms blocking read additionally to the 1 ms sleep in
retry_transfer_wrapper. I must fix my patch accordingly.
> I am not sure whether I am just imagining it, whether there was some
> good reason or whether it was due to some performance/high wakeup
> rate issues.
Maybe you wanted to write about it yourself because you find that design
ugly? I sure do.
Redesigning the protocol reads to eliminate active polling while allowing
interrupts, and allowing selection on multiple handles: maybe that could
constitute a GSoC task, since it is the period to throw wild ideas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel