IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Soon the g_lock database format will change. There will be one
exclusive entry and an array of shared entries. In that format,
there's no need to attach a lock_type to each entry in the g_lock
database. Reflect this change in the g_lock_dump API
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Feb 8 14:50:49 CET 2018 on sn-devel-144
4d404f2 added user-data for a g_lock. Print it in net g_lock dump.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
To be honest, it did not really make sense to just pass in
lock holders individually. You could argue that it made sense
with in reality only G_LOCK_WRITE around, but soon we will have
G_LOCK_READ and thus multiple lock holders on a single lock.
Now that we also have userdata, change the g_lock_dump API
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Jeremy Allison <jra@samba.org>
This simplifies the g_lock implementation. The new implementation tries to
acquire a lock. If that fails due to a lock conflict, wait for the g_lock
record to change. Upon change, just try again. The old logic had to cope with
pending records and an ugly hack into ctdb itself. As a bonus, we now get a
really clean async g_lock_lock_send/recv that can asynchronously wait for a
global lock. This would have been almost impossible to do without the
dbwrap_record_watch infrastructure.
TDB2 returns a negative error number on failure. This is compatible
if we always check for < 0 instead of == -1.
Also, there's no tdb_traverse_read in TDB2: we don't try to make
traverse reliable any more, so there are no write locks anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is the basis to implement global locks in ctdb without depending on a
shared file system. The initial goal is to make ctdb persistent transactions
deterministic without too many timeouts.
