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

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

[xcomp]

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

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

[Glynn Clements]

xcomp@arcor.de wrote:

> 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.

Do any of them say why?

The main reason for not doing too much inside a signal handler is that
only a handful of functions are specified as being safe to use from
within a signal handler.

If you are using user-space threads, you should protect "unsafe"
functions from being re-entered with semaphores or similar. Note that
functions which are re-entrant with respect to pthreads won't
necessarily be re-entrant with respect to user-space threading.

The pthreads library overrides a number of libc functions; the fact
that the pthreads version is re-entrant doesn't mean that the normal
version is. Also, some functions may use per-thread storage
(pthread_setspecific() etc), but this doesn't help if you only have
one "real" thread. E.g. errno is per-thread; functions which need to
check errno will be re-entrant for pthreads but not for user-space
threads.

Another reason is that the signal will be blocked while its handler is
executing. On platforms which don't queue blocked signals (Linux
does), only the first blocked signal will be received; the rest will
be lost. But this doesn't apply if you leave the handler via
swapcontext(), as each context has a separate signal mask.

-- 
Glynn Clements <glynn@gclements.plus.com>