samba - Unnamed repository; edit this file 'description' to name the repository.

Age	Commit message (Collapse)	Author	Files	Lines
2010-08-28	s3: Remove the dependency of g_lock on procid_self	Volker Lendecke	1	-9/+13
	procid_self() references global vars, don't depend on them unnecessarily
2010-07-05	s3: Pass procid_self() explicitly to messaging_ctdbd_connection()	Volker Lendecke	1	-3/+6

2010-05-06	s3: only include gen_ndr headers where needed.	Günther Deschner	1	-0/+1
	This shrinks include/includes.h.gch by the size of 7 MB and reduces build time as follows: ccache build w/o patch real 4m21.529s ccache build with patch real 3m6.402s pch build w/o patch real 4m26.318s pch build with patch real 3m6.932s Guenther
2010-03-12	s3: Add "g_lock_do" as a convenience wrapper function	Volker Lendecke	1	-0/+64

2010-02-16	s3: Fix timeout calculation if g_lock_lock is given a timeout < 60s	Volker Lendecke	1	-1/+6
	Detected while showing this code to obnox :-)
2010-02-16	s3: Slightly increase parallelism in g_lock	Volker Lendecke	1	-1/+7
	There's no need to still hold the g_lock tdb-level lock while telling the waiters to retry
2010-02-16	s3: Avoid starving locks when many processes die at the same time	Volker Lendecke	1	-6/+4
	In g_lock_unlock we have a little race between the process_exists and messaging_send call: We only send to 5 waiters now, they all might have died between us checking their existence and sending the message. This change makes g_lock_lock retry at least once every minute.
2010-02-16	s3: Avoid a thundering herd in g_lock_unlock	Volker Lendecke	1	-1/+16
	Only notify the first 5 pending lock waiters. This avoids a thundering herd problem that is really nasty in a cluster. It also makes acquiring a lock a bit more FIFO, lock waiters are added to the end of the array.
2010-02-16	s3: Optimize g_lock_lock for a heavily contended case	Volker Lendecke	1	-3/+36
	Only check the existence of the lock owner in g_lock_parse, check the rest of the records only when we got the lock successfully. This reduces the load on process_exists which can involve a network roundtrip in the clustered case.
2010-02-16	s3: Fix handling of processes that died in g_lock	Volker Lendecke	1	-3/+5
	g_lock_parse might have thrown away entries from the locks array because the processes were not around anymore. Don't store the orphaned entries.
2010-02-15	s3: Fix a typo	Volker Lendecke	1	-1/+1

2010-02-12	Fix warning messages on compile in g_lock.c Volker & Michael please check.	Jeremy Allison	1	-14/+4
	Jeremy.
2010-02-12	s3:g_lock: remove a nested event loop, replacing the inner loop by select	Michael Adam	1	-38/+101
	This made smbd crash in g_lock_lock() when trying to start a transaction on a db with an already started transaction, e.g. in a tcon_and_X where the share_info.tdb was not yet initialized but share_info.tdb was already locked by another process or writing acces to the winreg rpc pipe where the registry tdb was already locked by another process. What we really _want_ to do here by design is to react to MSG_DBWRAP_G_LOCK_RETRY messages that are either sent by a client doing g_lock_unlock or by ourselves when we receive a CTDB_SRVID_SAMBA_NOTIFY or CTDB_SRVID_RECONFIGURE message from ctdbd, i.e. when either a client holding a lock or a complete node has died. Doing this properly involves calling tevent_loop_once(), but doing this here with the main ctdbd messaging context creates a nested event loop when g_lock_lock() is called from the main event loop. So as a quick fix, we act a little corasely here: we do a select on the ctdb connection fd and when it is readable or we get EINTR, then we retry without actually parsing any ctdb packages or dispatching messages. This means that we retry more often than necessary and intended by design, but this does not harm and it is unobtrusive. When we have finished, the main loop will pick up all the messages and ctdb packets. The only extra twist is that we cannot use timed events here but have to handcode a timeout for select. Michael
2010-02-12	s3:g_lock: remove an unreached code path.	Michael Adam	1	-4/+0
	Michael
2010-02-12	s3: Implement global locks in a g_lock tdb	Volker Lendecke	1	-0/+594
	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.