Le 28 avril 2026 21:05:15 GMT+03:00, Nicolas George via ffmpeg-devel <[email protected]> a écrit : >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).
I never said that there wasn't a need for an I/O event loop. Everyone agrees that it's needed. Heck, even Anton agreed when he was around. But we can't unify I/O event handling with thread synchronization, in the sense that you can't register an event on a condition variable or a mutex. Sure, you can use pipes to wake up an I/O thread. You can also use event FDs. If you just want to end the thread, you can also use infamous thread cancellation. But that's obviously not the point. You're not unifying I/O and thread synchronisation by doing that. >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. You end up handling computational "busy" threads differently than I/O threads. That's not unifying. That's the whole point: this cannot be unified. _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
