-----Original Message----- From: Laurynas Biveinis [mailto:laurynas.biveinis@gmail.com] Sent: Donnerstag, 4. April 2013 21:59 To: Vladislav Vaintroub Cc: Sergei Golubchik; maria-developers@lists.launchpad.net; wlad@mariadb.org Subject: Re: [Maria-developers] Rev 3712: MDEV-4338 : Support atomic option on directFS/FusionIO
+ srv_use_atomic_writes = (ibool) innobase_use_atomic_writes;
Is that the typical usage pattern in the innodb code? Because it looks a bit silly to me, why couldn't you create a sysvar directly on srv_use_atomic_writes, why an intermediate innobase_use_atomic_writes variable?
Yes, this is typical usage pattern in Innodb. Bit weird, I agree. Every innobase_xxx variable has an srv_xxx counterpart. I have no clue why it is so, but I did not want to disturb their existing conventions:)
FWIW not necessarily. Look at innodb_io_capacity, innodb_purge_batch_size, innodb_rollback_segments, innodb_purge_threads just name the first few where a srv_* variable is specified in MYSQL_SYSVAR_* directly. Note that the srv_* = innobase_* assignments have typecasts on them, so I haven't checked, but it might be that using the srv_ in a MYSQL_SYSVAR_ directly would have resulted in compilation warnings otherwise.
Thanks, Laurinas, this is interesting. I tested it , using srv_use_atomic_writes directly. This gives me compiler error, not warning :) 6>..\..\..\storage\xtradb\handler\ha_innodb.cc(12654): error C2440: 'initializing' : cannot convert from 'ulint *' to 'char *' 6> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast Indeed, boolean values are handled consequently as "char" in MySQL (i.e my_bool is char ), and as "ulint" in innodb (ibool is ulint)
Just 2c, Laurynas