On Tuesday 17 June 2014 at 22:31:36, Ivan Shapovalov wrote:
> On Tuesday 17 June 2014 at 12:29:53, Edward Shishkin wrote:
> >
> > [...]
> >
> > Yup.
> > So, if discard is on, we work with 2 lists (delete_set,
> > delete_set_for_wander).
> > If discard is off, we work with one blocknr set..
>
> Good. So I'll do roughly following for v5:
> - rename discard_set_* to block_list_* and split off these definitions
> - write a family of reiser4_atom_dset_*() (log_deferred, log_immediate,
> apply_deferred, merge, init, destroy) which will encapsulate discard/nodiscard
> check and operate on correct lists (blocknr_set vs block_list)
> - call reiser4_atom_dset_{init,destroy,merge}() from respective functions
> - call reiser4_atom_dset_log_{deferred,immediate}() from reiser4_dealloc_blocks()
> - call reiser4_atom_dset_apply_deferred() from reiser4_post_commit_hook()
> - directly manipulate the block lists from discard_atom(), checking that we
> indeed have discard enabled
>
> Is this OK?
BTW, with txn_atoms there is a locking idiom involving E_REPEAT loops.
Is it fine to implement a
current_atom_dset_log_...(...) // E_REPEAT loop inside
instead of
atom_dset_log_...(txn_atom* atom, ...) // may return E_REPEAT
?
I mean, per coding style.
Thanks,
--
Ivan Shapovalov / intelfx /Attachment:
signature.asc
Description: This is a digitally signed message part.
