maria-developers team mailing list archive

["Vladislav Vaintroub" <wlad@xxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Laurynas Biveinis [mailto:laurynas.biveinis@xxxxxxxxx]
> Sent: Donnerstag, 4. April 2013 21:59
> To: Vladislav Vaintroub
> Cc: Sergei Golubchik; maria-developers@xxxxxxxxxxxxxxxxxxx;
> wlad@xxxxxxxxxxx
> 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