s3:g_lock: remove a nested event loop, replacing the inner loop by select
commit0a030b0de66e84f35637699377e44a083c445fa2
authorMichael Adam <obnox@samba.org>
Sat, 23 Jan 2010 00:17:06 +0000 (23 01:17 +0100)
committerKarolin Seeger <kseeger@samba.org>
Wed, 31 Mar 2010 15:54:31 +0000 (31 17:54 +0200)
tree177c311bb2a43dc11610b821fa0d9c47aacd00c5
parent84505cb3157d23b6df170bf694cd6adecc1fe9f5
s3:g_lock: remove a nested event loop, replacing the inner loop by select

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
(cherry picked from commit 83fffbeb44441a87569e543054af21d975eb20ae)
source3/lib/g_lock.c