31–40 of 57 posts
Wordpress strikes again. Page is from 2014. Archive link: https://web.archive.org/web/20091119184152/https://ph7spot.c... Edit: archive of 6 years ago with some styling: http://archive.is/B9He (The page actually loaded for me on the second try, and the design looks a lot more modern now.)
Your link says the page is from 2009, not 2014 (2009-11-19 to be exact).
And if you use XML, all you need to do, is to add another forward slash after the filename. And now, the network, the host and the data have become one: Everything is a node (or an atomic value). But hey, that's stupid. Let's not do that...!
Is the sendfile system call still the fastest way to transfer data locally on Linux systems? For communicating between processes running locally on system. Or, for example, a server running locally on an android device. Unix domain sockets typically beat TCP connections for most large file transfers. But is there anything faster? And what about transfers over the public net from machine to machine? I usually just use…
And I think there's some special casing in vmsplice that lets you transfer memory pages from process to process over a pipe. At least I've seen some patches for that, not sure if they made it into the kernel. Alternatively there's memfd.
But if you want to coordinate processes you'll use a shared memory and futexes.
If you just want to hand over an entire file to a different process you can send the file descriptor itself over a unix socket.
Which was the last Unix release/flavor where you could still read(2) a directory? All manpages that I've found say that you get EISDIR if you try it.
FreeBSD would allow this as of a few years ago (2007 at the earliest).
I like the Linus Torvalds' interpretation: that (almost) everything is actually a file descriptor. The few things that are not, like fork() returns, are subject to criticism (DJB wrote about how fork() should return an fd, I just couldn't find the URL right now.)
> Richard Stevens's 1992 book ``Advanced programming in the UNIX environment'' says that you can't safely mix select() or poll() with SIGCHLD (or other signals). The SIGCHLD might go off while select() is starting, too early to interrupt it, too late to change its timeout.
Solution: the self-pipe trick. Maintain a pipe and select for readability on the pipe input. Inside the SIGCHLD handler, write a byte (non-blocking, just in case) to the pipe output. Done.
Of course, the Right Thing would be to have fork() return a file descriptor, not a process ID.
I like the Linus Torvalds' interpretation: that (almost) everything is actually a file descriptor. The few things that are not, like fork() returns, are subject to criticism (DJB wrote about how fork() should return an fd, I just couldn't find the URL right now.)
This? http://cr.yp.to/docs/selfpipe.html > Richard Stevens's 1992 book ``Advanced programming in the UNIX environment'' says that you can't safely mix select() or poll() with SIGCHLD (or other signals). The SIGCHLD might go off while select() is starting, too early to interrupt it, too late to change its timeout. Solution: the self-pipe trick. Maintain a pipe and select for readability on the pipe input. Inside the S…
Earlier quoted context omitted.
This? http://cr.yp.to/docs/selfpipe.html > Richard Stevens's 1992 book ``Advanced programming in the UNIX environment'' says that you can't safely mix select() or poll() with SIGCHLD (or other signals). The SIGCHLD might go off while select() is starting, too early to interrupt it, too late to change its timeout. Solution: the self-pipe trick. Maintain a pipe and select for readability on the pipe input. Inside the S…
I have a faint recall of a DJB text with more in-depth discussion around the topic, thanks anyway for providing a true reference!
Earlier quoted context omitted.
> In Plan 9 , everything is a file Fixed that.
> > In Plan 9, everything is a file > Fixed that. It was a short snarky comment. Also the article mentions that too at the bottom. Yeah they "fixed it" but by that time not enough people cared. The abstraction purity was nice and developers and OS fans loved it, but it just didn't matter for most application. Another way to put it is that Linux was already fairly decent and it wasn't worth switching to a whole new OS…
Is the sendfile system call still the fastest way to transfer data locally on Linux systems? For communicating between processes running locally on system. Or, for example, a server running locally on an android device. Unix domain sockets typically beat TCP connections for most large file transfers. But is there anything faster? And what about transfers over the public net from machine to machine? I usually just use…
That depends on what you're doing. Sendfile, splice and copy_file_range are the fastest if you want to shovel things back and forth between file descriptors. The latter supports reflink copy if the the underlying filesystem does. And I think there's some special casing in vmsplice that lets you transfer memory pages from process to process over a pipe. At least I've seen some patches for that, not sure if they made i…
Oh, that is genius ;)
Described in detail here, from Stevens Unix Network Programming
http://www.masterraghu.com/subjects/np/introduction/unix_net...