On 02/11/12 20:15, Dmitry Yemanov wrote: > 11.02.2012 20:03, marius adrian popa wrote: > >> I will respond for 2) at first changing the offsets to 64bit doesn't >> look too hard replace SLONG with SINT64 >> in the lock.cpp functions >> but i might be wrong so i leave the core dev if is easy > First of all, this must be conditional depending on the target > architecture. It makes zero sense to have 64-bit offsets on 32-bit builds. >
The simplest part of the task. Just make them offset_t - very logical name for offsets :-) 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. > Also, many lock table internals are stored as offsets. Making them int64 > will make the every lock table being almost twice bigger in size. It's > likely to crash on heavily loaded 32-bit hosts (unless compiled > conditionally, see above) but it also may have performance implications > on 64-bit hosts (unless you have plenty of the unused RAM). 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. What about FB3 - may be we should start to think about lock-manager as replaceable dynamic library? ------------------------------------------------------------------------------ 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
