13.02.2012 11:39, Alex Peshkoff wrote: > The simplest part of the task. Just make them offset_t - very logical > name for offsets :-)
It depends on what headers you include. For example, our own offset_t defined in File.h is always 64-bit :-) > Certainly, a lot of places where lock size is calculated should be checked. > BTW - why signed values are used? As far as I remember end-of-list is 0, > not -1. As usual, magic numbers are used. See DUMMY_OWNER, for example. > Taking into an account that most of users do not need>2Gb of lock > table, 64-bit offsets (at least for 2.5) should better remain tunable > build parameter, turned off by default. I'm not really sure this is strictly required for v2.x. We surely must add an overflow protection, here I agree. But if it would be possible to have ULONG offsets instead of SLONG, it would double the limit. RedSoft could have their 2500 connections safely and nobody else is affected, so this sounds as a good compromise for a point release, IMHO. > What about FB3 - may be we should start to think about lock-manager as > replaceable dynamic library? I'm thinking about it for a long time already :-) And yes, it's likely to happen in v3. Dmitry ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
