Wednesday, June 20, 2007

Signals and Signal Handling

The embedded Linux workshop was a good introduction of getting into programming in the unix environment. I really got a chance to know the kernel better and how linux works. To talk about all of it in a single post would be superfluous and too lengthy, so I will share with you some of the parts that I've learned in a few post whenever the time is right and I suddenly have a caring and sharing mood.

Lets talk about Signals and Signals Handling. Some of the things here can be obtained by looking at man pages for the keyword signal.
Signals as we usually know it, is to kill -9, or kill HUP. We also know that a process can be interrupted, killed or even stopped. But thats what most system admins use, there are alot of things about signals that we don't know about. Particularly, signals are used to control the state of a process. And so, understanding signals will help us build applications and help us control its states and handle certain states of the processes.

As for now, there are two categories of signals, Standard signals, that we all use, are dependent on most processors, and are numbered from 1 to 31. These signals are called standard signals because its an implementation of the POSIX 1.1990 and POSIX 1. 2001 standard signals.

As real-time programming and real time processors becomes rampant, the need to handle real-time applications exist, and hence, linux also support real-time signals which is numbered from 32 to 63. If your application requires real-time handling, these are the signals that you will probably be playing with.

Of course all these signals will cause the program, or process to be in a different state. Is it important to know, yes, if you are writing an application and want to handle certain signals when the kernel sends the signal to your application or program.

For example, what if you would like to ignore the interrupt signal? You can do that with signal handling by catching the interrupt signal. However, you cannot just catch any signal that is being thrown to you, basically, you cannot catch the kill signal which is the number 9. And I also think you cannot catch the stop signal....(not sure on this, i was sleepy).

here is an example program that do just that, run a program on infinite loop, and disallow any interrupt from keyboard, for example ctrl-c.

#include ‹unistd.h› /* standard unix functions, like getpid()
#include ‹sys/types.h› /* various type definitions, like pid_t */
#include ‹signal.h› /* signal name macros, and the kill() prototype */


void sighandy(int i)
{
printf("Don't do that, I will ignore it: %d\n", i);
// signal(SIGINT, (void *) sighandy);
}

main()
{
signal(SIGINT, (void *) sighandy);
for(;;)
pause();
}

Write the program and save the program as test1.c in your favorite editor like emacs. Then, you can compile it using,

$ gcc -o test1 test1.c

To run the program, use

$ ./test1

try pressing Ctrl-c and see what happens, ideally, you should be able to catch the interrupt signal sent to the process currently running.

Hope that helps you understanding a bit. Now you can create an application that can catch signals. Stealing Niibe's favorite phrase, Happy Hacking guys.

Monday, June 11, 2007

fbgrab - Now, You Can Take Screenshot Anywhere
http://blog.irwan.name/?p=128

Sunday, June 3, 2007

Debian to conquer bukit tabur?


About 2 weeks ago, i went up and hike Bukit Tabur with a friend of mine. The view on top was amazing, and you can see KL and the Klang Gate Dam from the top of Bukit Tabur. After a 2 1/2 hour hike, I took a picture on top of the peak. I had nothing to show off except for my debian t-shirt. Anyways, I thought it would be a good idea if some of us did some non-geek activity for a change....
What say you, anybody want to claim that MyDebian conquers Bukit Tabur? It will be just about 4 hours all together....