From: Tor Didriksen
Date: September 30 2010 6:49am
Subject: Re: bzr commit into mysql-next-mr-bugfixing branch (tor.didriksen:3305)
 Bug#52002
List-Archive: http://lists.mysql.com/commits/119474
Message-Id: <4CA43315.4000108@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2010-09-30 08:24, Sergei Golubchik wrote:
> Hi, Tor!
>
> On Sep 30, Tor Didriksen wrote:
>
>    
>>>>>   +  An alternative would be to use _exit(EXIT_FAILURE),
>>>>>   +  but then valgrind would report lots of memory leaks.
>>>>>   + */
>>>>>            
>>>>
>>>>          
>>> Somehow I'm unhappy with valgrind workarounds, it obfuscates of
>>> correct code in order to please the tool, but well. I cannot propose
>>> anything better either.
>>>
>>>        
>> Well, mtr isn't really designed for crash/recovery testing.  For the
>> test cases involved here, I think it is better to simply kill the
>> server immediately, rather than to do a normal exit.
>>      
> mtr is will used for crash/recovery testing.
>
> Note that you simply cannot use exit() - it will execute destructors of
> the statically allocated objects, so the state will be different from
> "quit here, I said, immediately".
>
>    
my alternative implementation would be _exit(), which does not run any 
atexit() calls

> In particular - I'm not sure it's  the case now, but it was earlier -
> MYSQL_LOG_BIN closes binlogs in the destructor and marks them as
> "properly closed". Thus there is no XA crash recovery on startup,
> because, according to binlog, mysqld was shut down gracefully.
>    

Static objects are evil, especially in multi-threaded programs.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Static_and_Global_Variables

> In that sense kill -9 is the most close to power failure.
>    
Which is exactly what I'm doing :-)

> Regards,
> Sergei
>
>    

-- didrik