>>> Are there any database-level ASTs known to implicitly access the
>>> attachments? When should they lock the appropriate mutex?
>>
>> Database-level ASTs not need to access attachment internals usually.
>
> "Usually" differs from "always" :-) I seem to remember cases when the
> AST saves lck_attachment into tdbb_attachment and then it could be
> accessed by lower levels even for database-level locks (lck.cpp with
> att_long_locks comes to mind first).
IIRC, i removed tdbb->setAttachment() from database-level ASTs, at least it
was
my intention. Anyway, AST's routines requires careful re-thinking. So far i can
be
more or less sure about BDB and NBackup ones only.
>>> Do we really need the SharedCache option in production?
>>
>> It was implicitly introduced by Alex and i just add it to the config file. I
>> see no problem
>> if we remove it - less options is less headache for us and for users :)
>
> This was exactly my point :-)
Good :)
>>> But what are the benefits of SuperClassic in v3.0?
>>
>> For end users - i don't know. For us to easily debug Classic mode -
>> definitely.
>
> Debugging is surely must be supported, but I'm believe we could make it
> possible without exposing the SharedCache option to the public.
No problem for me.
>> I always said that Affinity should work even for Classic.
>
> And on POSIX? ;-)
Yes, of course.
Regards,
Vlad
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
