[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming.threads

Re: Using sigsetjmp/siglongjmp from multithreaded application

gyhuang

3/31/2015 6:59:00 PM

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.



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!
2 Answers

Andy [Ex-MSFT]

10/4/2007 9:24:00 PM

0

I posted a huge response, but I don't think it took for some reason, maybe I
responded to you Shane, but here's my response again, and I added some
stuff...

"Shane Nokes" <shane@nospam.hotwiredpc.cXoXm> wrote in message
news:D5D928AD-9B5B-4317-AC12-60BF98AD7116@microsoft.com...
> Halo2 on Integrated Intel Graphics?
>
> If it even works (which 90% certain it won't, I'm a system builder) it
> will give you around 3-5 Frames Per Second.
> You need at least 30 frames per second to have any sort of smoothness to
> the game at all.
>
> I would honestly recommend getting at least the Radeon X1900, however I
> doubt your current PC could handle the HD2900 due to the heave power
> requirements.


Holy crap an x1900 for HALO 2?!

Whatever dude, if you need 60+ frames per second and you have $250 to spend
on a video card you certainly could do worse than a x1900, but if you just
want to play the game, what you have "WILL" work, and if it DOES NOT work,
it may not be the video card you're having problems with.

Just saying, it's not going to be a stellar experience, but it WILL run. I
have TF2, HalfLife2 and Halo 2 running on a notebook with a x1200 mobile
card. Like I said NOT STELLAR, but it works (Vista Ultimate).

I've been in game development (Mostly QA, management, etc.) on and off since
97, I got my start in support getting DOS games to run in Windows 95
enviornments, don't wave your "system builder" flag at me like I don't know
what I'm talking about. Now a days that's like saying you're a private in
the army. I'm not trying to say you don't know your shit, but I hope you
understand what I'm trying to say here.

If I didn't state my point of view clearly enough in my first post then I
apologize, but NOTHING gets my Internet Flame on then when people say you
need a really high end piece of hardware, when an "OK" piece of hardware
will do the job.

Lets break it down...

Great gaming experience:
ATi HD 2900 Dx10
nVidia 8800 GTX Dx10
ATi x1900 or x1950 Dx9
nVidia 7900 Dx9

Good Gaming:
nVidia 8600 Dx10
ATi HD 2600 Dx10
nVidia 7900 or 7800 Dx9
ATi x1700 or x1800 Dx9

OK Gaming:
nVidia 7600 Dx9
ATi x1600 or x1650 Dx9

Poor Gaming (But it'll work):
Just about any integrated chipset made in the last year.
nVidia 7300, ATi x1300

Some of the new Intel graphic chipsets are supposed to surpass similar stand
alone cards and cost hundreds less, so while they may not be uber, if you're
on a budget they won't kill ya.
--
ADDITIONAL.

BBPS.com just posted the official Epic recommended specs for UT3, thought
you might get a chuckle...
--snip--
Midway and (those guys Silicon Knights hate) Epic have revealed the PC
specifications for the upcoming first-person shooter, Unreal Tournament 3
and even typing the minimum requirements on my current box is experiencing
slowdown.

Minimum System Requirements
Windows XP SP2 or Windows Vista
2.0+ GHZ Single Core Processor
512 Mbytes of System RAM
NVIDIA 6200+ or ATI Radeon 9600+ Video Card
8 GB of Free Hard Drive Space

Recommended System Requirements
2.4+ GHZ Dual Core Processor
1 GBytes of System RAM
NVIDIA 7800GTX+ or ATI x1300+ Video Card
8 GB of Free Hard Drive Space

Okay, while they aren???t nearly as hefty as other upcoming titles (Sup,
Crysis?), the seemingly annual leaps of technology from one video card to
the next reminds me why most gamers have flocked toward the accessibility of
consoles rather than PCs.
--snip--
wow, min specs is a 5 year old video card from ATi, cpu requirements are up
there though.

ATi, as I've been told, designs all their graphic chipsets around DirectX
specs, and nVidia makes their own specs and uses drivers to adapt them for
DirectX. I remember early dev of certain games and we had to swap out nvidia
cards for ATi, just so the game would run. Odd.

512 ram in vista, wonder what that's gonna be like?


-A.

sp9804

4/1/2015 7:05:00 PM

0

(I'm retaining the three-year old original article.)

In article <d0f72c4d-f70c-440e-aea1-173275458910@googlegroups.com>,
<gyhuang@ucdavis.edu> 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
<http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15....

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