10 ms·
Totally, off topic, but it's funny to think about what kind of the feature would be if we put "un-" on each syscall: unseek unselect unpipe unsync etc.
by euske 7y ago
Totally, off topic, but it's funny to think about what kind of the feature would be if we put "un-" on each syscall:
unseek
unselect
unpipe
unsync
etc.
- colonwqbang 7y agounselect(2) Description: put thread to sleep as long as there is activity on any fd, wake up only when all fds are inactive. Useful for: Scheduling work to be performed only when server is idle. unsync(2) Description: Select a random file, load it into the buffer cache, and remove it from file system. Useful for: Freeing up some disk space in a pinch. unwait(2) Description: Resurrects the previous child process. Useful for: Implementing the !! operator in bash. unsignalfd(2) Description: Invoke signal handler whenever a given fd activates. Useful for: User space interrupts. unopen(2) Description: Create a file which refers to an open fd. Useful for: Implementing /proc/self/fd functionalit.
- marcosdumay 7y ago> unselect(2) > Useful for: Scheduling work to be performed only when server is idle. Yeah that's nice. > unsignalfd(2) > Useful for: User space interrupts. There is libfam. At least on my system, it doesn't have a manual page. > unopen(2) > Description: Create a file which refers to an open fd. That does sounds useful, and I don't know any library that does it.
- datenwolf 7y agoThe "unopen" syscall actually exists, albeit under a different name: linkat https://linux.die.net/man/2/linkat https://linux.die.net/man/2/linkat
- colonwqbang 7y agoI don't think it's the same thing. Linkat is still starting with a file that exists in the filesystem. In my silly world, unopen() would just take any fd (socket, file, pipe, etc.) and create a file system binding which anyone could open. Kind of like how /proc works on Linux today.
- geofft 7y agoEmacs somewhat famously uses "unexec" in its build process, you build a skeletal Emacs in C (mostly the Emacs Lisp implementation), run it, load and compile and process a bunch of Lisp that implements the editor itself, and dump the resulting process memory back out to disk. The result of this eldritch process is the final emacs binary. When you exec emacs, you get an environment that consists of the editor code ready to go.
- aasasd 7y agosquints Sooo... Elisp has AOT compilation!
- lilyball 7y agoI'm given to understand that the macOS implementation of malloc had to have special-cased code in it just to support emacs due to this approach.
- saagarjha 7y agoFor the curious: https://opensource.apple.com/source/libmalloc/libmalloc-166.251.2/src/frozen_malloc.c.auto.html https://opensource.apple.com/source/libmalloc/libmalloc-166....
- tambourine_man 7y agoWhy?
- jandrese 7y agoBecause linkers are too easy? It really looks like some overly clever college student's weird trick that somehow managed to survive for decades in an established product.
- jws 7y agoIt comes from a time of machines executing instructions thousands of times slower than they do now. Literally – thousands. Memory access was about as fast as an instruction execution, so the amount of compute you can justify per unit of data was hundreds of times less than it is now. They did however have virtual memory systems with on demand page fetching. Also, that machine was being time shared with a dozen or more users. Launching emacs or TeX on this machine might take tens of seconds without access to unexec(), but only 3 seconds for the freeze dried version. unexec() was easier at the time. There were no shared libraries, no address space layout randomization. One memory region grew up from the bottom, one down from the top. There was no mmap() jamming mysterious stuff in the middle. Just copy the bottom, copy the top, do magic to adjust the stack for your unexec() call, and write the thing out as an executable. (Yeah, I excised unexec() from BibTeX back in the ‘80s to port it to a 68k Mac for a coworker, then later implemented unexec() for a Motorola 88k based multilevel secure SysV system in the early ‘90s because launching emacs was driving me insane. I prefer our shiny new future of stupidly fast computers.)
- jdoliner 7y agounopen
- reportgunner 7y agountouch
- alienallys 7y agounkill
- moocowtruck 7y agounfinger
- Emigre_ 7y agounbowed unbent unbroken
- ars 7y agoungetc does actually exist.
- lifthrasiir 7y agoOr `unlink`.
- ultrarunner 7y agoununlink would be pretty useful. Then again, this kind of exists; I have fond memories of a panicky younger me struggling with undelete in DOS.
- marcan_42 7y agoununlink is link() on a /proc/<pid>/fd/<fd> entry. Assuming some process still has the file open, that is.
- coldtea 7y agoDoes that mean that one could implement "undelete" by changing open() so that some central process (let's call it "recycle-bin") also opens a copy at the same time a process opens them (but keeps it open until you send it a "empty" signal), and then calling that link()?
- wichert 7y agoYou could use LD_PRELOAD to replace unlink with a version that passes an fd to a running recycle-bin daemon. That approach doesn't really have much, or any, advantage over just moving files to a recycle-bin folder and keeping track of items in there.
- claudius 7y agoIt would "automatically empty" the recycle bin at each shutdown though.
- microtherion 7y agoSurely, "unseek" should be called "lhide".