> -----Original Message----- > From: Laurynas Biveinis [mailto:[email protected]] > Sent: Donnerstag, 4. April 2013 21:59 > To: Vladislav Vaintroub > Cc: Sergei Golubchik; [email protected]; > [email protected] > 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 _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
