Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • L LHCb
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 163
    • Issues 163
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Jira
    • Jira
  • Merge requests 67
    • Merge requests 67
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • LHCb
  • LHCb
  • Issues
  • #179

Closed
Open
Created Jan 10, 2022 by Rosen Matev@rmatevMaintainer0 of 1 task completed0/1 task

Add support for 'write only' entries in the TES which have multiple views referring to them

The following discussion from !3303 (merged) should be addressed:

  • @graven started a discussion: (+2 comments)

          // addBank,adoptBank or removeBank on the underlying RawEvent...
          // TODO: `writeViewFor` (see https://gitlab.cern.ch/gaudi/Gaudi/-/merge_requests/1151 ) 
          //       should be extended to allow it to be used for this case as well, as that would 
          //       make the underlying `RawEvent` inaccessible, and thus _ensure_ it will not be 
          //       modified (not even by code that doesn't play by the rules, provided it is not
          //       explicitly/maliciously tailored to do this)

Note that writeViewFor allows to put a single 'view' in the TES in combination with a single inaccessible 'parent' which maintains the validity of the view. For the above, what is needed is a way to specify multiple views to use the same 'parent', while keeping the parent inaccessible, i.e. multiple views (and hence multiple TES locations) sharing the same parent. Hence the parent can not be stored with any one of the views (unless we go for a 'hacky' solution such as storing the parent as a shared_ptr with each view, which will work, but which does not take advantage of the fact that the lifetime of the parent, as long as it is in the TES, is already fine, and it introduces unnecessary overhead when deleting the TES entries...).

An alternative is to wrap (move) the parent into a 'box' which is does not provide an interface for retrieving the parent, and store the box in the TES -- so while one could still get the box from the TES, there is nothing that could be done with it... This can actually be implemented trivially by re-using the existing writeViewFor setup, which already hides the 'parent', by only providing an utterly useless 'view':

   struct OpaqueView {
       QpaqueView() = default;
       template <typename T> OpaqueView(T const&) {}    
   };

With that simple view, one can just do: writeViewFor<RawEvent,OpaqueView> to really make RawEvent inaccessible (but keep it around for the lifetime of the event)

Edited Jan 27, 2022 by Gerhard Raven
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking