xcomp@xxxxxxxx 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@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
