Initial Discussion

want:
- give the drp a psana-python script
- drive that psana-python script by calling psana_set_dgram(Dgram*) (would replace the file reading)

...

(1) and (2) could be put into the same psana-python process. (4) is a separate python process.

Some Technical Details

• shmem ownership/cleanup
  • valerio uses sysv ipc instead of posix_ipc (because the conda version of posix_ipc claims to not support message queues, but a pip-installed version does: this should be a solvable problem ... feels like it's not built optimally?) 
  • unlike our shmem there are not physical in /dev/shm
  • for sysv we control the naming of the numeric keys (which are the equivalent of the filenames) so we can avoid permissions issues that way.  currently the numeric key is formed from the thread number and partition number.  Ric suggests perhaps adding the primary XPM number (cpo points out this is indirect, somehow ideally would use "username").  maybe not such a big issue because the username is controlled by the platform number and procmgr.conf.
• pebble size (both for transition buffers and L1 buffers: the maximum of these two is used for the drp-python shmem)
  
  • in Ric's new mode the pebble size is determined from the .cnf, or defaults to .service if not specified (used to be the .service) but drp-python can return a dgram larger than the pebble size.  what do we do?
  • we will manage the two bufend's in the drp-python and we will crash if that gets exceeded
  • if we have low-rate large events, could be better to assert damage rather than crash
    • Ric says maybe this is the job of the fex?  cpo says it might be better if we could solve it in one place for all possible fex's.  since truncating the data corrupts it then we have to mark the xtc as corrupt/not-iterable.
    • A downside of not crashing:  people won't realize there's a problem