Skip to content

io: Correct handling of byte count pos in TBufferFile::ReadObjectAny#21192

Open
pcanal wants to merge 21 commits intoroot-project:Arlesiennefrom
pcanal:Arlesienne_ByteCount
Open

io: Correct handling of byte count pos in TBufferFile::ReadObjectAny#21192
pcanal wants to merge 21 commits intoroot-project:Arlesiennefrom
pcanal:Arlesienne_ByteCount

Conversation

@pcanal
Copy link
Member

@pcanal pcanal commented Feb 8, 2026

This is a missing commit for #21183 which was merge a bit too soon.

@pcanal pcanal requested a review from jblomer February 8, 2026 16:48
@pcanal pcanal self-assigned this Feb 8, 2026
@pcanal
Copy link
Member Author

pcanal commented Feb 8, 2026

Note that 588b29e was also not reviewed.

@github-actions
Copy link

github-actions bot commented Feb 8, 2026

Test Results

    22 files      22 suites   3d 4h 53m 53s ⏱️
 3 829 tests  3 828 ✅ 1 💤 0 ❌
75 746 runs  75 737 ✅ 9 💤 0 ❌

Results for commit ef03d21.

♻️ This comment has been updated with latest results.

@ferdymercury
Copy link
Collaborator

Closing #20498 since it seems this is an alternative / better approach

@pcanal pcanal force-pushed the Arlesienne_ByteCount branch 2 times, most recently from 1ca66ec to 33e27a1 Compare February 17, 2026 18:33
@pcanal pcanal requested a review from linev as a code owner February 17, 2026 18:33
@pcanal
Copy link
Member Author

pcanal commented Feb 18, 2026

@jblomer This is ready for a final review. Note that the last commit (733ac65) is not really part of this PR but is necessary to make the test work as is (That last commit will be replaced on the master by a more general solution).

@pcanal
Copy link
Member Author

pcanal commented Feb 23, 2026

Closing #20498 since it seems this is an alternative / better approach

No per se :). I think that part of #20498 is already merged into either master or the Arlesienne branch and what is left may or may not be needed.

pcanal added 8 commits March 4, 2026 13:44
This fixes TBufferFile::ReadObjectAny handling of long range byte counts
Those were essentially replaced by a 'set the cursor to the end'
call in commit 7d25b75.
It is dubious whether these changes are needed or were an heurestic
to ignore (temporarily !?) race conditions.
Due to the need for using a stack of bytecount position, we can no longer support redundant
calls to CheckByteCount.
@pcanal pcanal force-pushed the Arlesienne_ByteCount branch from 0b030d7 to 1f88b1f Compare March 4, 2026 19:44
pcanal added 11 commits March 4, 2026 15:11
This simplify the implementation of calling `ReserveByteCount`
and then `SetByteCount` and could also simplify removing the
use of the ByteCountStack in some/most cases.

Note: `ReserveByteCount` is protected and the existing code
that does the same semantic action was only recording the position
in a 32 bits integer.  That code needs to be updated by either
making `ReserverByteCount` public (making removal of external use
of the ByteCountStack more difficult) or by introducing a RAII
that hides the size of the integer.
In order to allow using the roottest CMake macro outside of the roottest sub-directory,
we need to make the variable used by those macros 'cache variable' so that they can use
elsewhere.

This is a hack and works only after the second CMake configuration/invocation.
When using the Microsoft Visual Studio generator we have the exact same problem,
that it might trigger a rebuild of ROOT so we need to apply the same solution.

See 06e00a2.

PS. We might want to eventually rename the resource lock.
It is need by at least Ninja and the Visual Studio generator
@pcanal pcanal force-pushed the Arlesienne_ByteCount branch from 1f88b1f to ef03d21 Compare March 4, 2026 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants