This is getting slightly offtopic, but what the heck, there are not many posts in this forum anyway...

> In my opion, an easier more natural way [...]

One could also argue that signals would be more natural, because the problem solved by forumGuy does not require a means to carry data; It's only the notification that is desired, since there are no commands other than ``write PID''. Signal loss need not be a problem either, for the reasons I mentioned earlier.
But as you said, this is a matter of personal taste and preference.

> their reception will intercept your code's stack and therefore the work they can do is very limited.

Actually, it's not the stack that limits the usability of signal handlers. Unless you specify your own stack for signal handling (using the sigaltstack() function), its use of memory will be much the same as that of a simple nested function call, including the usual automatic expansion of stack space if its current end is reached.

The real problem is that static data might be corrupted if a signal is posted while the normal path of execution uses and relies on static data that will also be accessed by the signal handler. If write access of variables also reda or written by signal handlers is not protected by blocking signals (analogous to the way you have to block interrupts in the top half of a device driver so it does not interfere with updates from an interrupt handler), interolerable race conditions will result (there are also tolerable race condition, but that's another story).

All variables have to be volatile-qualified to begin with. If the normal path of execution is in the process of updating a shared resource, the signal handler might find it in an incosistent state. This is, however, a solvable problem, as I said: Block signals as needed and you can write away.

Unsolvable problems arise when the standard C library comes into play (this is the real reason why signal handlers are not very powerful). A function you intend to call from within a signal handler must be guaranteed to be reentrant, because otherwise a code path running this function might be using static data. If a signal calls the same function, it will invariably corrupt this static data and your program will break.

Even if the function happens to be unused at a certain point, the behavior of calling it from within a signal handler is still undefined and should not be relied on. The POSIX list of functions that are guaranteed to be called safely from a signal handler is very short. To begin with, it excludes ALL Pthreads-related functions, so you cannot e.g. signal a condition variable and unlock a mutex from within a signal handler.
-------------snip--------------

> When you write a value to a pipe, when is the value removed?

As soon as a reader of the pipe read()'s the data.

> Also does anyone have same code of creating pipes and assigning them to child processes?

Code:

int     fds[2];
pid_t   pid;
if (pipe(fds) == -1) {
        /* Handle error */
}

if ((pid = fork()) == -1) {
        /* Handle error */
} else if (pid == 0) {
        char    buf[128];
        int     rc;
        close(fds[1]);
        if ((rc = read(fds[0], buf, sizeof buf - 1)) == -1) {
                /* Error */
        } else if (rc == 0) {
                /* Other end closed by parent */
        } else {
                buf[rc] = 0;
                puts(buf);
        }
        close(fds[0]);
} else {
        close(fds[0]);
        if (write(fds[1], "hello world", sizeof "hello world") == -1) {
                /* Error */
        }
        close(fds[1]);
}

I didn't test this, but something along the lines should work... Again, I refer you to the pipe() and read() and write() manual help pages in case you need more information.