13.02.2012 13:45, Alex Peshkoff wrote: >> I'm not really sure this is strictly required for v2.x. We surely must >> add an overflow protection, here I agree. > > A check in shared memory grow code should do a trick.
Sure. >> 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. > > May be use 1,2,3 instead -1,-2,-3 for 'magics' like DUMMY_OWNER? > IMHO real offsets can't be so small. Interesting idea. But how should the conditions like (offset < 0) look now? Something like (offset < sizeof(lhb)) doesn't look elegant. Maybe explicitly compare with all the magic numbers? >>> 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. > > The worst is the moment when that library is going to be unloaded. All > the rest looks quite easy to do. We already have a refcount for the lock manager. 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
