Lynne (12021-02-19): > https://github.com/libuv/libuv/tree/v1.x/docs/code > Pipes, file descriptors, sockets, examples. > The docs are even searchable: http://docs.libuv.org/en/v1.x/index.html
I have found all this. Nothing allows to handle a foreign protocol handled by existing code. It is even stated explicitly in the docs: everything assumes libuv owns the fd. That means no ALSA, no libX11/xcb, etc. > > Yes, that is a terrible trend. Throw memory and CPU at I/O performance > > instead of writing optimized code. POSIX threads never were a solution > > for parallel I/O. > They kind of are, since I/O is blocking on most platforms No, they are not. We had non-blocking I/O working perfectly way before POSIX threads were even remotely stable. I have come to understands that "threads as a solution for I/O" is a Windows solution. > You seem really prejudiced towards anything 'infected' by node, big data, > or http servers, but they've been solving the issues we have now since > before we knew we even had them. Unfortunately, their solutions are industrial ones, i.e. throw money at the problem. I want a hacker solution: throw efficient programming at the problem. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
