Roy's musings

Simiar to kqueue framework in FreeBSD, Solaris 10 introduced a framework called Event Completion Framework (ECF). ECF is a very powerful concept that can be used when an application wants to wait for asynchronous events - like read/write events on sockets. Traditionally one would use poll()/select() for these events. There is enough discussion already on how primitive these mechanisms are and how they don't scale well on large number of file descriptors. Another advantage with kqueue and ECF is that you can wait on different kind of activities, not just activities on file descriptors. For e.g. when a process calls fork, or when a process calls exit, etc. There are a few resources that would be very useful in understanding these frameworks: Robert Benson's article on ECF Sample program given in Bart Smaalder's blog Jonathan Lemon's paper on kqueue Oh btw, I think Linux is yet to have a mechanism as powerful as these.

Let us begin with the sample code below (headers omitted for brevity): int main(int argc, const char* argv[]) { void* mmap_ptr = mmap (NULL, sizeof (pthread_mutex_t), PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANON, -1, 0); if (mmap_ptr == MAP_FAILED) { perror ("mmap failed"); return -1; } fprintf (stderr, "mmaped at: %x\n", mmap_ptr); pthread_mutex_t* mutp = (pthread_mutex_t*)mmap_ptr; // initialize the attribute pthread_mutexattr_t attr; pthread_mutexattr_init (&attr); pthread_mutexattr_setpshared (&attr, PTHREAD_PROCESS_SHARED); // this is what we're testing // initialize the mutex pthread_mutex_init (mutp, &attr); pthread_mutexattr_destroy (&attr); // acquire the lock before fork pthread_mutex_lock (mutp); pid_t chld = fork (); if (chld != 0) { // parent fprintf (stderr, "parent: going to sleep...\n"); sleep (30); fprintf (stderr, "parent: unlocking.\n"); pthread_mutex_unlock (mutp); } else { /...

Today I solved an interesting problem. One of my fellow developers used system() function in his code to run some command. The code looks like: while (condition) { if(system (...) == 0) dosomething (...); sleep (...); } When we ran the application, I observed that the system was crawling. I verified the IO utilization and found it was normal. I checked the CPU utilization using top and that too was normal. When I did a ps, I found that there were too many defunct processes in the system. I grabbed a cup of coffee and dug what could have caused so many defunct processes. There was only one place, which I suspected, could have caused the defuncts. That piece of code is given above. So I thought what was wrong with the argument to the system () command. It goes something like this: system ("head -1 input.txt | grep pattern") I modified the command above as it would be executed in system (), and run it through truss to find out if all the forked processes are reaped using wait...