I/O impl and TBasket::Streamer


still working on my pure-Go ROOT I/O reader, I’ve stumbled on a file that triggers this piece of code in TBasket::Streamer:

      if (flag == 1 || flag > 10) {
         fBufferRef = new TBufferFile(TBuffer::kRead,fBufferSize);
         char *buf  = fBufferRef->Buffer();
         if (v > 1) b.ReadFastArray(buf,fLast);
         else       b.ReadArray(buf);
         // This is now done in the TBranch streamer since fBranch might not
         // yet be set correctly.
         //   fBranch->GetTree()->IncrementTotalBuffers(fBufferSize);

The file is coming from the LHCb OpenData dataset:

(-> PhaseSpaceSimulation.root)

I was wondering what exactly that was doing?
it seems that this is some extra basket data coming from some spillover data (coming from the very last events?) that may or may not be shared between all the baskets ?
(I am saying this because the last fBasketEntry element value is less than the total number of entries in the file…)

could someone document (or point me to the documentation of) the meaning of the various flag values ?

perhaps a question for @pcanal :slight_smile:


The flag are ‘explained’ by code in the write section of the Streamer :slight_smile:

     if (fHeaderOnly) {
         flag = 0;
         b << flag;
      } else {
         flag = 1;
         if (!fEntryOffset)  flag  = 2;
         if (fBufferRef)     flag += 10;
         if (fDisplacement)  flag += 40;
         b << flag;

I.e. it indicates in a ‘shorter’ way than usual whether an optional entity (here fEntryOffset, fBufferRef and fDisplacement) needs to be store with the TBasket.


Thanks a lot.
So… In a few words, what does this fBufferRef do?
What is it meant to contain?
And how is it meant to be used?

(Apologies for the barrage of questions…)


It contains the ‘user’ data corresponding to the branch. It is basically the payload of the TBaskets when it is stored as a TKey (the normal pattern).

Here, somewhat surprisingly, the last baskets of the branch is stored along-side/within the TBranch itself and thus inside the key containing the TTree.

So one question is how has this file been produced as it seems to have skip (or found a deficiency in) the mechanism supposed to flush all the outstanding basket when the TTree meta-data is written to disk. (Namely TTree::Write calls TTree::FlushBaskets).


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.