On Tue, Mar 25, 2008 at 05:04:05PM -0400, Lon Hohberger wrote:
[Note that I'm intentionally playing both sides of this discussion]
> I don't know the internals of the asynchronous API, but it looks pretty
> cumbersome to use with a tree structured configuration if the structure
> of the tree itself is dynamic.
Well, you could certainly set everything up for callbacks, and
then navigate the tree when a callback is seen - the worst of both
worlds, but I bet a number of folks will do it :-)
> With a sync API, you can build your queries as you go:
>
> get_config_attributes_recursive(key, node) {
<snip>
> }
>
> In the case of rgmanager[2] (which currently uses CCS), this happens
> frequently enough that it's interesting; admins can craft services in
> any structure they want.
There are two issues here. First, it's expensive. You're
navigating 10s or 100s of nodes that have not changed, over the network
no less. Second, as Steve points out, it has a race condition; the
config you see at query time may not be the config at the time the
callback was queued. With a callback scheme, guaranteed ordering means
everyone sees the same config deltas in the same order.
That said, the race condition doesn't matter sometimes, and the
linear style is *way* cleaner to read/maintain. When the race condition
doesn't matter, it's really good to allow the linear style. But we
have to provide the callback style for applications where the race is
important - something you just can't get in ccs today, afaik.
Joel
--
"There is no sincerer love than the love of food."
- George Bernard Shaw
Joel Becker
Principal Software Developer
Oracle
E-mail: [EMAIL PROTECTED]
Phone: (650) 506-8127
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
