OSDev.org

I'm currently busy implementing pipes in my os and i was wondering how they are dealt with in other oses. I specifically refering here to situations where pipes are used for ipc.

Say process A creates a pipe and sends the two ends to processes B and C. Can they communicate with each other? And what happens if process A terminates? How does the os know when to close a pipe? How does it know another process won't use it again? Would B and C actually just be able to use the pipe? What if process D guessed the pipe id? Could it use the pipe without authorization?

I think these questions show what i'm unsure of. I have tried to find out how other oses do it, but with on success. I realise i can just decide how it will be done in my os, but i want to first know how others do it. I'm refering to both hobbie oses and proprietary ones here.

liquid.silver wrote:I'm currently busy implementing pipes in my os and i was wondering how they are dealt with in other oses. I specifically refering here to situations where pipes are used for ipc.

In Unix, a pipe is just an ordinary file (from the point of the programmer) you can write to and read from. You open a pipe like a file, and read from it or write to it like a file. A named pipe actually resides in the file system and can be used by any process that may access the pipe, I don't recall how unnamed pipes are accessed.

I really don't understand what you mean by a process A sending the 'ends' of a pipe to processes B and C. If I understand what you are saying, aren't you talking more about message channels?


JAL

I don't recall how unnamed pipes are accessed.

IIRC they are given a filename in /tmp and accessed as named pipes.

Process A would be using some sort of handle to access each end of the pipe. I was referring to just passing that handle. Also i'm referring to unnamed pipes.

In unix when do the pipes disappear? Obviously if they are specifically closed, but if they aren't, and the process terminates and leaves them open, what happens?

liquid.silver wrote:Process A would be using some sort of handle to access each end of the pipe. I was referring to just passing that handle. Also i'm referring to unnamed pipes.

Yeah, but then they'd have to be global handles, instead of local ones (which is more usual).

In unix when do the pipes disappear? Obviously if they are specifically closed, but if they aren't, and the process terminates and leaves them open, what happens?

Unix, like other decent OSes, cleans up after processes that leave resources open.


JAL

But what i'm getting at is when does the os cleanup the unused resources? How does it know that the resources are unused?

If you stored a list of open files/handles for each process, add to it when someone does fileopen/pipeopen or whatever and remove from it when they do fileclose. When the process ends, make implicit calls to fileclose for all handles remaining in the process' list.

Is that how other oses like linux and windows do it? I was planning on doing something similar to that in my os, i just want to know other methods.

liquid.silver wrote:Is that how other oses like linux and windows do it? I was planning on doing something similar to that in my os, i just want to know other methods.

Yes, even DOS did this, although I'm not sure whether it actually cleaned up after a program. Unix does so yes, and Windows as well. In general, it is a good idea to do resource tracking, an OS should never rely on a program closing file handles, freeing memory, etc.


JAL

So if process A makes a named pipe and sends the name to process B. Then A terminates. Can process B then use the pipe? And if an unnamed pipe was made?

The standard way to create a pipe on Unix, is to call mkpipe() which "returns" two file descriptors. See the manpage, but basicly one end can be written to, and the other end read from..

Internally the pipe is basicly a ringbuffer and a couple of semaphores. Nothing fancy. The size is typically around 4k or so.. thought that isn't really all that important.

Such a pipe exists as long as either end of the pipe is open. It's cleaned after you close() the both ends. There's a couple of ways to move file descriptors from a process to another on a typical unix system, but most common way is to not:

when you write a pipe command line, it's the shell that calls mkpipe() and then when it fork()s the processes to do the work, it does some filedescriptor renaming (see dup()) to get the right descriptors at the right places before it finally exec()s the programs. edit: remember fork()ed childs inherit the parents open file descriptors by default

Named pipes are similar, except they sit somewhere in the filesystem, and if you open the named pipe repeatedly, you get the same pipe every time.. anyway, just more ringbuffers kludged to have a filename.

And with the named pipe, how long does the entry in the filesystem exist after noone has it open?

liquid.silver wrote:And with the named pipe, how long does the entry in the filesystem exist after noone has it open?

It remains until you delete it...

I wrote:[brynet@ttyp0]~/named-pipe: $ mkfifo happy-pipe
[brynet@ttyp0]~/named-pipe: $ ls -li
total 0
467721 prw-r--r-- 1 brynet brynet 0 Dec 6 17:00 happy-pipe
[brynet@ttyp0]~/named-pipe: $

Notice the p in the permissions..

Thanx. I think i understand what i wanted to know about implementations of pipes

Anyone care to add some of this info to the wiki? ('Unix Pipes')