>[For the record, I'm not saying your code is wrong -- I didn't even look at
>it. I'm only correcting your statement about simultaneous open files.]
>Because transmitting file contents is generally considered the most costly
>part of describing a tree delta, the editor interface allows you to describe
>all the "tree changes" and property changes before transmitting any file
>content changes. (This allows editor implementations to detect
>out-of-dateness and conflicts before the file content changes are
>transmitted). So, for example, the following is valid:
> # transmit tree structure changes
> d1 = open_root()
> d2 = open_dir('A')
> f1 = open_file('A/mu')
> d3 = open_dir('A/B')
> f2 = open_file('A/B/alpha')
> f3 = open_file('A/B/beta')
> close_dir(d3)
> close_dir(d2)
> close_dir(d1)
> # transmit post-fix text deltas
> apply_textdeltas(f1)
> close_file(f1)
> apply_textdeltas(f2)
> close_file(f2)
> apply_textdeltas(f3)
> close_file(f3)
> # complete the editor drive
> close_edit()
>Naturally, in such situations, you don't want to open your file batons in
>pools that will be destroyed when their parent directory baton's pool is
>also destroyed. You need instead for file baton's to have lifetimes that's
>about as long as the whole editor drive.
Thanks Mike for explaining this. Then such a long living pool would cause
similar leak!!!
With regards
Kamesh Jayachandran
