Rémi Denis-Courmont via ffmpeg-devel (HE12026-04-27): > Those are two different problems, or rather, we have no choice but to treat > them as such. You can't properly unify a main loop for intra-process inter- > thread synchronisation (as with frame threading and slice threading) and one > for external events (as for network protocols). > > There are simply no portable ways to multiplex waiting on a condition > variable or another thread synchronisation primitive versus on a file > descriptor (or a socket/HANDLE on Windows). And if you only care about > Linux, then the relevant > but broken-by-design support for FUTEX_FD was dropped in 2.6.25. > > And sure, some people would probably point that you can use anonymous > pipes, or Linux-specific event file descriptors, as a thread > signaling. But that's much slower than using futeces, especially on > the fast paths.
The fact that Unix I/O and POSIX threads synchronization do not mesh is common knowledge. It is too bad you stopped there at “can't be done”, because we DO need an event loop for non-trivial protocols, and even for trivial protocols in non-trivial applications, and we DO need it to be multithreaded to reduce the risk of lost packets in high throughput streams (this is the reason we have the UDP thread). So what do we do? Well, we have busy threads performing computational tasks controlled through lightweight thread synchronization primitives, and we have I/O threads that spend most of their time blocked in poll() or equivalent and that we wake with some kind of self-pipe or with a siglongjmp() or a system-dependant method to communicate with them. And the I/O threads offload their processing to busy threads to go back to listening. The point is, from the point of view of the application it is all the same: whether it is for the sockets of multiple RTP streams or for the heavy processing of a complex filter graph and an expensive codec, it just runs an instance of AVOrchestrator or whatever we want to call it. -- Nicolas George _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
