| Title | Telemetry output not appropriate for interactive use |
| Status | open |
| Priority | nice |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | The telemetry system uses buffers internally and only output the buffers (via EventSync) when one of them becomes full. This means (in theory) that an event can languish in a buffer for arbitrarily long before being output. This is not suitable for monitoring of a running program, which we hope to support as part of job001150. However, we avoid the worst effects of this because of a lucky combination of the following features: 1. Some event kinds accumulate events very rapidly in some types of client program. In particular, in a program with automatically managed memory, there is an event for every fixed reference (of kind Ref). This leads to a full event buffer on a regular basis, at least during the scanning phase of a collection. 2. EventFlush is called when any buffer is full. 3. EventSync is called by EventFlush, even if the buffer that just became full belongs to a kind that is not actually going to be output because they are excluded by the telemetry control word. We should not have to depend on luck to be able to monitor live programs. |
| Analysis | How else could we do it? Ideally we would have a timer that goes off with a configurable frequency and call EventSync. But that's hard to do portably and we might be able to get a good enough solution by maintaining a global timer and checking it in ArenaPoll (since we have to call ClockNow here anyway). But what about non-polling builds? Maybe we don't care about live monitoring of non-polling programs since these aren't suitable for interactive use. |
| How found | inspection |
| Evidence | None |
| Created by | Gareth Rees |
| Created on | 2018-06-22 14:50:30 |
| Last modified by | Gareth Rees |
| Last modified on | 2018-06-22 14:51:37 |
| History | 2018-06-22 GDR Created. |