Dmitry, All,
On Mon, 2017-03-20 at 20:06 +0300, Dmitry Yemanov wrote:
> >> It also might be possible to use shared memory for synchronization
> >> instead of lock manager calls to speed things up.
> >
> >Could you explain more ?
>
> I suppose Nickolay means replacing GlobalRWLock with native
On 03/20/17 20:06, Dmitry Yemanov wrote:
> 20.03.2017 19:43, Vlad Khorsun wrote:
>>> Firebird doesn't use signals for AST delivery for a long time already
>>> and it might be possible to issue new locks from inside AST handler.
>>>
>>> Therefore it might make sense to go back to this logic. This
20.03.2017 18:06, Dmitry Yemanov wrote:
> I suppose Nickolay means replacing GlobalRWLock with native OS-level RW
> primitives used similar to shared memory mutexes. For Windows, they're
> just shared as named objects, for POSIX they're stored in shmem.
On Windows they also could be Critical
20.03.2017 20:06, Dmitry Yemanov wrote:
>
> Agreed. But I'm really worried about taking locks in ASTs, this sounds
> as a dangerous practice to me. I smell new deadlocks.
Just to clarify: I meant taking LM locks here. It could be safer for
low-level locks.
Dmitry
20.03.2017 19:43, Vlad Khorsun wrote:
>
>> Firebird doesn't use signals for AST delivery for a long time already
>> and it might be possible to issue new locks from inside AST handler.
>>
>> Therefore it might make sense to go back to this logic. This would make
>> nbackup state locks very
Hello, All!
It appears I now have some time to look into old issues.
I know for a long time that it is possible to optimize NBAK module:
Currently, difference file page is allocated inside CCH_mark and this is
sub-optimal.
This has not been the case during nbackup development. Early version
