Careful with both hands while using fork!

fork() is one of the most useful feature of C/Linux/UNIX. But it's like a double edged sword, so be careful with fork :-)
Of late, I got stuck in a weird problem with one of the client application(A) that interacts with another application(B). Application A was hanging when used application B; otherwise alone A runs just fine.
Now what to do? We did a thorough examination of both the applications and found that A is waiting on a pipe P. P has its write end with B and A has got the read end. But why this wait? There is no need to keep this pipe open in first place.
So here fork() comes in to picture. Actually A forks B and then B interacts with A. When A fork() B, B gets a copy of all open file descriptors(FD) of A as well. There you go!
After getting these FDs, B does not take care to close them. But A checks if any of its FD is still open. Since the file is open with B, kernel will tell A that some of your files are being accessed. So just wait :( And this wait never ends...
This was it. A simple close() call in B for all FDs worked for us. And B happily got away with A.

A word of advice: Always call exit() from child. exit() does basic clean up and calls _exit() which more work including closing all files open with child.

Just to verify, you can use this test program:

#include "fcntl.h"
#include "stdlib.h"

int main()
{
int fd = -1;
int status;
char buf[512];

fd = open("abc.txt", O_CREAT);

int pid = fork();

if(pid == 0) { // Child
puts("Child says bye");
exit(status);
} else { // Parent
sleep(1);
int ch = read(fd, buf, 16);
printf("\nRead returns %d\n", ch);
exit(status);
}
}

Lichen: Our first invention

We, a group of three friends have got our first ever invention disclosure published today. It's quite a happy moment for all of us. We started with a small idea that eventually got transformed into a serious paper :)

Title : Lichen: A Framework For Characterizing Sporadic Performance Constrictions In Non-deterministic Applications"

The idea deals with better profiling of application with a special way of sample collection.
Our paper is published in worldwide publication Research Journal. (http://www.researchdisclosure.com)

Terminal problem with csh/ksh

If you are a bash addict and you have to work in csh/ksh; you may face terminal problem with csh/ksh while using vi/more or any such command. vi expects complete knowledge of the terminal where it's going to display its contents. There is a simple way to fix it.

1. First get the shell type by: $echo $SHELL
This is just to confirm that you are in csh/ksh.

2. Figure out what is the terminal type. If you do not know then ask your system administrator.

3. If you can't, that's also okay. :-) We'll try to use default terminal emulator type called "vt100".

4. Now you need to export the terminal type to your csh/ksh.
$setenv TERM vt100
$tset

5. There you go. Try to open a vi session.

Let me know if you face any issue.