nobody knows what GET_RECENT is supposed to do

[dd1]

there is some disagreement over what GET_RECENT is supposed to do and whether it works. K.O.

[Stefan Ritt]

Here is the original idea: Assume you write a single event display, where you always want to show the most recent event, not an event at the beginning of the SYSTEM buffer which might be half an hour old. This is usually required since you look at the event, change something in hardware and then want to see the effect immediately and not half an hour later.

So the GET_RECENT was designed such that not the consumer skips events, but that the producer checks all consumers when adding a new event. If it finds a consumer with the GET_RECENT flag, it pushes the read pointer of that consumer to the currently added event. This avoids any overhead on the consumer side of skipping old events. The consumer would have to search for the latest event, while the producer knows already what the last event it.

I tested this quickly when I implemented it 25 years ago, but do not use it anywhere, so no guarantee that it’s working.

[dd1]

From discussion with Stefan:

• GET_ALL - returns all events in the same sequence as bm_send_event() writes them, starting from the first event written after we made the request (reader rptr is set to buffer wptr)
• GET_SOME - same, but if event buffer becomes full, some events are lost
• GET_OLD - (not implemented) instead of returning the first event written after we connect, return the oldest events still in the buffer (reader rptr is set to buffer rptr)
• GET_NEW - (not implemented) always waits for a new event (before each read, reader rptr is set to buffer wptr)
• GET_RECENT - returns the last matching event in the buffer (GET_ALL/GET_SOME returns the first matching event).

K.O.

‌

[dd1]

current implementation of GET_RECENT returns the first matching event that is younger than current time minus 1 second, see bm_check_requests() “if (ss_time() - pevent->time_stamp > 1) { skip this event }”. K.O.