[PATCH] Core ldb modules changes

[simo]

On Fri, 2008-01-18 at 10:57 +1100, Andrew Bartlett wrote:
> On Thu, 2008-01-17 at 18:48 -0500, simo wrote:

> > Yes probably of a side effect of calling ldb_wait and intercepting it it
> > was working even with LDAP, but trust me it was *really* dirty.
> 
> I still think this is a regression, and aside from your feeling that it
> was 'dirty', I still don't see why it had to be lost.

It's not a feeling, it was simply working by chance, it was not allowing
to do real async calls, ie without looping around ldb_wait() which is
not async at all.

> The point of an async API is to avoid having to collect data.  With this
> limitation, we may as well make it sync. 

The point of an async API is to not block, and nothing else.
Collecting data has nothing to do with that.
Sync APIs are about not collecting data and doing all the processing
while others wait.
Yes real async code is sometimes more complex, but in all honesty, while
rewriting modules using this paradigm I also found that I was
simplifying and streamlining the modules, making them much more
understandable and uniform.

> > This also helps getting just one outstanding call at a time, with the
> > previous method you could end up with countless outstanding calls and
> > some ldap server has limitations on the number of calls each single
> > client can have outstanding, so the previous way may also lead to
> > unpredictable results.
> 
> I'm prepared to bear with that risk, or control that when issuing new
> requests.  I think being unable to usefully use the callback provided is
> an important regression. 

It simply does not work, see this simple scenario:

request -> module 1 (down request 1) -> backend

backend (reply to req 1) -> module 1 (down request 2) -> backend

backend (reply to req 1) -> module 1 (down request 3) -> backend

backend (reply to req 3) -> module 1 (done req 3)

         ^^^^^^^^--- note being async you can get
                     out of order replies too (not
                     handled in current modules)

backend (reply DONE to req 1) -> module 1

At this point:

   you have your original request finished, but not all the down
requests are so you need to do synchronization and keep track explicitly
of each request inside the module. You have to make sure you keep around
data if they come out of sequence. You have to make sure you know which
one is the last one of the many you have standing because you have to
send the upper module a callback when you are done and not before.
This makes for way more confusing code and lots of bugs waiting to
happen.

Serializing calls make modules much more simple to understand, debug and
make work.

Simo.



-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>