mechanism which does not involve rlibmap anymore but
rootcling instead.
Basically all the calls to the macro calling rlibmap have been
removed.

Signed-off-by: Danilo Piparo <danilo.piparo@cern.ch>
Signed-off-by: Fons Rademakers <Fons.Rademakers@cern.ch>

which happens through rootcling and not anymore through rlibmap.

Signed-off-by: Danilo Piparo <danilo.piparo@cern.ch>
Signed-off-by: Fons Rademakers <Fons.Rademakers@cern.ch>

Provided by Justin Salmon, Lukasz Janyst (CERN/IT).

In the case of array data member (both variable size and fixed size),
CompareContent was incorrectly reporting mismatches.

In the case of a counter variable, whether it is marked as a counter
variable or a regular variable might depends on the derived class used.
(This is the case for TCollection where fSize is used as to hold the
size of a variable size array only in some cases).  This results in
different files containing a different TStreamerInfo (for TCollection)
depending on what collections were stored in the file.  CompareContent
was upgraded to correctly ignore the difference.

This fixes ROOT-5151.

Signed-off-by: Fons Rademakers <Fons.Rademakers@cern.ch>

This (new) routine can be used from custom streamers
when it is known that the class was always versioned
(and thus never stored a checksum within the buffer).
This allows to disambiguate the case where the class
used to have a version number equal to zero and did
not save a byte count and is now versioned.

When reading the version number being zero, without
the byte count we have no way to guess whether the
class was version un-versioned or had previously a
version number equal to zero.

In the case where the class used to have a version number set to 0
(i.e. don't stream any of its content) but the version number is
now set to greater than zero, we need to avoid reading a non-existant
checksum from the buffer.

Signed-off-by: Fons Rademakers <Fons.Rademakers@cern.ch>

No need to hold the gROOTMutex while executing ResetGlobalVar.

This avoid nesting the collection and the meta-data mutex.

The major change is that the utility routine returned by
TVirtualCollectionProxy::GetFunctionCreateIterators
now has the prototype:

typedef void (*CreateIterators_t)(void *collection, void **begin_arena, void **end_arena, TVirtualCollectionProxy *proxy);

i.e. adding a new pointer to the virtual collection proxy so
that in the case where the routine can not hard code all
the information (for example in the case of emulated collection
proxy) it can now get the information from a the CollectionProxy
without relying on the calls to PushProxy (which we are trying
to deprecate in general as it is somewhat thread adverse).

If a read rule does not a specific target, the corresponding StreamerElement
has a name that is not one of the data member (past or present) and thus
they need to be handled explicitly in TBranchElement::InitializeOffset.
A new 'bit' (kWholeObject) is introduced to explicitly distinguish those
type of StreamerElement.

(cherry picked from v5-34-00-patches commit db8ea810)

Avoid race condition when moving from one TFile to another in a TChain by using a TSemaphore to mark the fact that there are still some prefetch requests in flight. By using this we ensure that the TTreeCache ( i.e. also the TFilePrefetch obj) is moved to the next file only when all in-flight requests are received. There are three things we need to take care of when moving the cache:
- make sure the async thread is not doing any work
- clear all blocks from prefetching and read list
- reset the file pointer in the prefetch obj

This was discovered when testing Prefeching on Alice jobs.  While using it on TChains, we discovered a race condition which was quite hard to replicate on a simple test machine and required some traffic shaping to spot it.

[From Elvin]

For CMS backward compatibility, allow SetCacheRead to disconnect the cache from being the current cache, but keep the file attached to the cache.

git-svn-id: http://root.cern.ch/svn/root/branches/v5-34-00-patches@45321 27541ba8-7e3a-0410-8455-c3a389f83636
(cherry picked from v5-34-00-patches commit eac731d2)

Now roottest has been fixed too.

This reverts commit 285a268e.
It needs additional changes in roottest.

Update the StreamerElement search in TBranchElement::InitializeOffsets
to always try to find a StreamerElement that points to one of the member
of the actual class.   This allows for properly finding the offset
of the local object within the outer object.  The previous version
was somtimes looking at 'cached' StreamerElement; however their local
offset are (often) different that the non-cached version and the
main offset is very often different.   The previous code was then
applying this offset to both the actions for the cached StreamerElement
and for the regular StreamerElement.  For the cached element the
two actions compensated each other.  For the regular element if
the local object had an object within the main object, this was
leading to the 'reading' of the local object overwriting content
in the main object.

Now the offset is calculated for the local object in regard
to the outer object using one the StreamerElement that points to
one of the member of the actual class *and* AddToOffset is
not applied to the cached object (since they are never part
of an outer object the offset is always zero).

This fixes ROOT-5437
(cherry picked from commit 4fe9faed)

In the case a read rule applies to the current StreamerInfo,
which is used for writing, there was no good StreamerElement
describing the location and means to write the data member
(unless there was a repating element).

Now, in this case we introduce yet another StreamerElement
and mark it as a 'Write' element.  We also ignore it in
the 'right' places and similarly ignore the caching and
artificial element when writing.

For example with writeTree.C in roottest/root/io/datamodelevolution/misc
we get:

StreamerInfo for class: MyClass, version=1, checksum=0x36b5f1f8
  MyClass@@1     @@alloc         offset=  0 type=1001
  TObject        BASE            offset=  0 type=66 Basic ROOT object
  TObjArray      fArray          offset= 24 type=61  (cached)
  TObjArray      fArray          offset=  0 type=61  (write)
  TObjArray      fArray          offset= 16 type=1000
  MyClass@@1     @@dealloc       offset=  0 type=1002
   i= 0, @@alloc         type=1001, offset=  0, len=1, method=0
   i= 1, TObject         type= 66, offset=  0, len=1, method=0
   i= 2, fArray          type= 61, offset= 24, len=1, method=0 [cached]
   i= 3, fArray          type= 61, offset=  0, len=1, method=0 [write]
   i= 4, fArray          type=1000, offset= 16, len=1, method=0
   i= 5, @@dealloc       type=1002, offset=  0, len=1, method=0
(cherry picked from commit c7e58492)

Add the information about whether a StreamerElement is
designed for writing.
Factor the collection of this information into a single
routine TStreamerElement::GetSequenceType to centralize
and normalize the generation of this string (instead of
being partially duplicated in 4 places).
(cherry picked from commit f078d990)

(cherry picked from the v5-34-00-patches branch
 from commit 0020441a)

(cherry picked from the v5-34-00-patches branch
 from commit 6dab04e7)

Since v5.34/10 and v6, we store in StreamerElement of the StreamerInfo
of a class with a CollectionProxy the name of the content type.
It stored in the StreamerElement's title at the beginning in the form:

  <ContentType>

We can now use this information to recreate a proper collection proxy
in the emulated case.
(cherry picked from the v5-34-00-patches branch
 commit 86b327dd)

(cherry picked from the v5-34-00-patches branch
 commit 983852ce)

Store in the StreamerElement of the StreamerInfo of a class with a
CollectionProxy the name of the content type.
It stored in the StreamerElement's title at the beginning in the form:

  <ContentType>

We will be able to use this information to recreate a proper collection proxy
in the emulated case.
(cherry picked from the v5-34-00-patches branch
 commit 9509aab2)

From Sergei Linev.