[PATCH] CTDB protocol and client fixes

[Amitay Isaacs]

On Tue, Nov 24, 2015 at 5:48 PM, Volker Lendecke <Volker.Lendecke at sernet.de>
wrote:

> On Tue, Nov 24, 2015 at 05:33:23PM +1100, Amitay Isaacs wrote:
> > Since no one has replied to this email, let me summarize.
> >
> > 1. For some reason I cannot fathom, async processing is treated
> *different*
> > from sync processing.  A global event context for all async processing is
> > ok, but for sync processing need lots of temporary contexts.
>
> When you use tevent_loop_once deep inside the call stack where some
> other tevent_loop_once is also active, anything can happen. As long as
> callers work without tevent_loop_allow_nesting then it might be workable.
>
> > 2. I can drop the tevent_context from sync API, but it will still use the
> > cached event context rather than creating a new one for every sync API
> > call.  This is because of the current design of the client API.  It was
> > designed to not use tevent_add_fd() for reading each individual packet
> from
> > an fd.
>
> "cached event context" is something that I am worried about using in
> smbd and winbind.  We have gone through a lot of work to remove this from
> the core smb libraries. You might prove me wrong by finding spots where
> we are not there yet, but in the SMB libraries I would see that as
> a bug that needs fixing.
>

The cached event context arises only in sync API which will be primarily
used in the ctdb tool and some of the test code.  Samba would never use
CTDB's sync API, but (I am hoping) will be converted to use CTDB's async
client API.

Questions are:

1. Should I keep the sync API completely separate, so it's not used by any
code other than CTDB.  As I mentioned before, the new client API is not a
public library yet.  When we make CTDB client API public, then it can only
publish the async version and not the sync version.

2. More fundamental question: Should I get rid of the optimization of not
using tevent_add_fd() for reading each individual packet from an fd?  This
avoids the extra system call, but requires the use of same event context.
If no one else cares about it, I would be willing to get rid of it.

Amitay.