And no they are not acccessed by any other thread than the main thread.

The problem we had, if I remember correctly, was an exit() had been inserted in 
the
signal handler. This "pulled the rug out from under" the main thread of course.
But that problem was quickly fixed once we realized what it was doing.
And I dont see  that it was related to statically allocated objects.
Even if we had dynamically allocated objects with static pointers, the same kind
Of crash would have occurred.

/AndersBj

-----Original Message-----
From: Anders Björnerstedt 
Sent: den 9 oktober 2013 19:23
To: Anders Widell; Hans Feldt; mathi.naic...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [devel] [PATCH 1 of 1] opensaf: change daemon_exit to call exit() 
[#581]

Played with exit?
Are you referring to the episode with illegal stuff in the signal handler ?

/AndersBj 

-----Original Message-----
From: Anders Widell
Sent: den 9 oktober 2013 16:28
To: Anders Björnerstedt; Hans Feldt; mathi.naic...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1 of 1] opensaf: change daemon_exit to call exit() 
[#581]

Wasn't it IMM that got into trouble last time we played with exit() :-)

These objects will be destroyed when we call exit(). Are they accessed by any 
thread besides the main thread?

Anyway, I suppose it wouldn't be too hard to change these variables into 
pointers, and initialize them the first thing we do in main() ?

regards,
Anders Widell

2013-10-09 16:12, Anders Björnerstedt skrev:
> The imm uses static global (non-pointer) variables for a number of C++ STL 
> objects.
> Maps, Sets, Vectors etc.
>
> I have never seen any problems with this.
>
> /AndersBj
>
> -----Original Message-----
> From: Anders Widell [mailto:anders.wid...@ericsson.com]
> Sent: den 9 oktober 2013 15:52
> To: Hans Feldt; mathi.naic...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [devel] [PATCH 1 of 1] opensaf: change daemon_exit to 
> call exit() [#581]
>
> Ack from me.
>
> I guess we should also go through the code and make sure we follow this rule 
> from the Google C++ Style guide:
>
> Static and Global Variables
>
> Static or global variables of class type are forbidden: they cause 
> hard-to-find bugs due to indeterminate order of construction and destruction. 
> However, such variables are allowed if they are constexpr:
> they have no dynamic initialization or destruction.
>
> regards,
> Anders Widell
>
> 2013-10-03 14:54, Hans Feldt skrev:
>>    osaf/libs/core/common/daemon.c |  9 ++++++---
>>    1 files changed, 6 insertions(+), 3 deletions(-)
>>
>>
>> By calling exit() instead of _Exit() registered exit functions are 
>> called. This enabled for example flushing of gcov data.
>>
>> diff --git a/osaf/libs/core/common/daemon.c 
>> b/osaf/libs/core/common/daemon.c
>> --- a/osaf/libs/core/common/daemon.c
>> +++ b/osaf/libs/core/common/daemon.c
>> @@ -355,13 +355,16 @@ static void sigterm_handler(int sig)
>>    }
>>    
>>    /**
>> - * Exit process with a standard syslog message
>> - * To be called after the service has cleaned up per service 
>> specific things
>> + * Exit calling process with exit(0) using a standard syslog message.
>> + * This function should be called from the main thread of a server 
>> + process in
>> + * a "safe" context for calling exit(). Any service specific thing 
>> + should be
>> + * cleaned up before calling this function. By calling exit(), 
>> + registered exit
>> + * functions are called before the process is terminated.
>>     */
>>    void daemon_exit(void)
>>    {
>>      syslog(LOG_NOTICE, "exiting on signal %d", SIGTERM);
>> -    _Exit(EXIT_SUCCESS);
>> +    exit(0);
>>    }
>>    
>>    /**
>
> ----------------------------------------------------------------------
> -------- October Webinars: Code for Performance Free Intel webinars 
> can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the 
> most from the latest Intel processors and coprocessors. See abstracts 
> and register > 
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.c
> lktrk _______________________________________________
> Opensaf-devel mailing list
> Opensaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensaf-devel



------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Reply via email to