Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: sp9804@butternut.contek.com (Douglas Wells (USENET)) Newsgroups: comp.programming.threads Subject: Re: Using sigsetjmp/siglongjmp from multithreaded application Date: Wed, 1 Apr 2015 19:05:06 +0000 (UTC) Organization: None Lines: 95 Message-ID: References: Injection-Info: mx02.eternal-september.org; posting-host="385bafa31e23122b46dad9e05ea4880b"; logging-data="21730"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19QyLLlCG0u1KNDiUD2FW/Z" X-NNTP-Posting-Date: Wed, 1 Apr 2015 19:05:06 +0000 (UTC) XX-Trace: butternut.contek.com 1427915106 1268 127.0.0.1 (1 Apr 2015 19:05:06 GMT) X-NNTP-Posting-Host: localhost X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Cancel-Lock: sha1:kSKO1VCqAr1ln7x42lAgsJw4Pog= Xref: csiph.com comp.programming.threads:2949 (I'm retaining the three-year old original article.) In article , wrote: >On Friday, July 20, 2012 at 2:42:22 PM UTC-7, Michael Podolsky wrote: >> Hi All, >> >> I am writing a stack tracing code and to make this code safe I want to >protect myself from a SIGSEGV. >> >> So I chose to process SIGSEGV and jump from a signal handler to a >position set by sigsetjmp. Then, to my disappointment I found that there >is no straightforward solution to associate a sigjmp_buf buffer with a >particular thread. >> >> I can't use standard thread local storage or implement it by myself >with mutexes because these functions should not be called from a signal >hanlder. >> >> And, I don't want to run stack tracing code under a mutex as the >performance of application may degrade -- otherwise I could solve my >task by having one thread only at risk of SIGSEGV and one sigjmp_buf per >whole application. >> >> So, going back, is there a robust way in linux to write a multithread >application in which some critical parts of code are SIGSEGV-tolerant? >> >> Thanks in advance! >Hi >I met a similar issue. Finally I use thread specific key as follows: >function(){ > Sigjmp_buf localbuf; > pthread_setspecific(pthread_key_t key, (const void *)&localbuf); > > if (sigsetjmp(localbuf, 0) != 0) { > //assign error > //return error > } > //done with everything > pthread_setspecific(pthread_key_t key, NULL); >} > >void signal_handler(int sig) >{ > if (sig == SIGSEGV){ > void * sigjmplocal =pthread_getspecific(pthread_key_t key); > if (sigjmplocal) > siglongjmp(*(Sigjmp_buf*)sigjmplocal, 1); > > } >} > >From book, SIGSEGV is sent to the thread that triggers it. >Is it safe to use this approach? It seems working with simple UT. But I >can not foresee its risk. > >Thanks a lot. No, not according to the rules established by the earlier poster: >>I can't use standard thread local storage or implement it by >>myself with mutexes because these functions should not be >>called from a signal hanlder. You're using the function pthread_setspecific in a signal handler. This is not allowed by POSIX. (And I believe that Linux just follows POSIX in this regard.) There are only a very few functions that you are allowed to execute in a signal handler. Look up the concept "async-signal-safe." You might start in section "2.4.3 Signal Actions" of . It's not at all clear that there is a way to solve this problem in general. Here are a few suggestions: - Your current code is likely (but not guaranteed) to work on many current platforms, including Linux. You could just live with that restriction. - If your rate of thread creation is low, you might be able to create a static, shared list of task-id to storage pointer associations (i.e., reimplement pthread's thread-specific storage). pthread_self() IS on the list of routines allowed to be used in a signal handler. But, the maintenance of this list will be complicated and require lots of use of atomic-variables in order to comply with POSIX. - It's possible that the thread-storage mechanism in C11 and C++11 can be used for this. The standard is not clear to me. Some sections hint that it might be supported; other hint that it might not. I don't know of an interpretation on this. Good luck, - dmw -- Douglas Wells . Connection Technologies . Internet: -sp201504- -at- -gmail.com- .