Page History
...
- how to configure
- see above for use on configdb
- when do things happen
- should start drp-python in config phase1: Ric suggests do the process-fork at startup, then have the python interpreter switch which scripts it runs at configure phase1.
- (a detail) FYI: worker threads get shutdown on unconfigure (is this necessary? Ric says maybe some array sizes change. Ric thinks changing startup/shutdown times would be a lot of work.)
- 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
Overview
Content Tools