Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Alboin wrote:Anyone care to add some of this info to the wiki? ('Unix Pipes')
I basicly copied my post to the wiki, with a notice for somebody else to clean it up. Anyone else copy their own posts if they think they're relevant.
Though, ultimately I think it would be most helpful if whoever asked the question would copy the info to the Wiki as a sort of "pay the community" because then it would be the information that help that would end up in the Wiki.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
I'm guessing that was hinted at me I don't mind doing it, it's just gonna take a while as i'm actually on holiday atm and doing all my posting from my phone, so it'll have to wait till i get back. So if there's no rush, i'll do it in a while. I do agree that it would be best for me to do it though.
liquid.silver wrote:I'm guessing that was hinted at me I don't mind doing it, it's just gonna take a while as i'm actually on holiday atm and doing all my posting from my phone, so it'll have to wait till i get back. So if there's no rush, i'll do it in a while. I do agree that it would be best for me to do it though.
Nah it wasn't ment like that. I just honestly think that it might be a good idea in general to have the people asking be the people to extend the wiki, 'cos that might get the right info in there.. no idea if it's workable in practice.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Linux implements pipes by overriding file operations in the inode associated with the pipe.
Opening a pipe results in an inode structure, that keeps a count of readers and writers in a pipe info struct. As previously noted, it operates something like a ring buffer. When all readers and writers are removed, the pipe inode information is freed.
A pipe, as a special case file/inode, needs to have an associated filesystem. A named pipe is associated with whatever filesystem it is created on. An unamed file is associated with 'pipefs'. Deletion of the pipe inode is handled by the filesystem layer. A named pipe could theoretically linger for as long as the inode remains in memory - though the pipe info would be destroyed. An unnamed pipe's inode will be destroyed when the readers and writers count hits 0 (right after the pipe info is destroyed).
Linux pipes are very simple because they get to inherit all the work done for regular files.
I really don't have a problem with it and i totally agree with the principle. The knowledge gained in the forums must be translated into the wiki. I looked at the new wiki article and i think it's a good summary but maybe the last post by Fate should be included, or at least part of it. You can almost never have too much info in the wiki.
Article looks fine to me. The only note i had was that using mkfifo does not create a pipe but a persistent name for a pipe, which will be created when attempting to access that name. (That is a fairly subtle distinction though.)
Come on people, don't tell what you want in the Wiki; instead just write it there. That trivially converts meta-work into the real thing, and takes about as much time.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
I don't mind doing it, it's just gonna take a while as i'm actually on holiday atm and doing all my posting from my phone, so it'll have to wait till i get back. So if there's no rush, i'll do it in a while. I do agree that it would be best for me to do it though.
