Is it bad to let a signal handler stay alive for a long time

[xcomp@arcor.de]

Hi all,
I am still thinking about a preemptive scheduling implementation in user-mode. Therefore I have switched from using setcontext to calling swapcontext in the signal handler. This approach seems to solve the problem I had with setcontext in the signal handler (in my test program for loops does not finished correctly in every case).
But now I ran into another question: If I am using swapcontext inside the signal handler its context stays alive for a long time (because other contexts are running before the handler can finish its work). I didn't find any trouble caused by this till now. But I've found also many sites where they say that a signal handler should include only a small amount of code so that it can finish fast.
So my questions are: Can anyone explain, why it is still a bad idea to use swapcontext inside the signal handler, although there seem to be no problems with it? If there are, which problems can occur? Does anyone has a good idea for a stress test in order to find problems? Simply running a huge number of code does not seem to be enough.
I appreciate any responds.

Thx,
Matthias

Erwischt! Bei Arcor sehen Sie die besten Promi-Bilder riesengroß und in Top-Qualität. Hier finden Sie die schönsten Schnappschüsse auf dem roten Teppich, lernen die Frauen des Womanizers Boris Becker kennen und schauen den Royals ins Wohnzimmer. Viel Spaß auf Ihrer virtuellen Reise durch die Welt der Stars und Sternchen: http://vip.arcor.de.
--
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html