Feb 19, 2021, 14:52 by geo...@nsup.org: > 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. >
File descriptors are reference counted. So if something takes ownership of an FD (completely reasonable, since it may want to clean up, seek, and flush+close it afterwards), then you can just dup() it before giving it to libuv. >> > 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. > Windows is something we explicitly support. So we need something which works on Windows as well, otherwise we still lose a very very large majority of users. >> 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. > That's some very prejudiced thinking. Their solutions are ugly because they got paid for it? Maybe they got money because their hacker solutions failed after someone put in much more effort than what's reasonable? By that logic a lot of our code is also "throw money at the problem". Frame threading for decoders is definitely up there. What about reference counted frames? There's a time and a place for hacker solutions, but this area's definitely not it, unless TempleOS integration is more important than having Windows support. _______________________________________________ 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".
