in the process of switching to a more batch processing approach. so far, seems like it can keep up

This commit is contained in:
2025-11-06 11:58:19 +01:00
parent 2ccf37ce33
commit 5f95e82a3c
5 changed files with 452 additions and 188 deletions

View File

@@ -59,8 +59,8 @@ struct __attribute__((__packed__)) MonitorEvent {
struct __attribute__((__packed__)) NormalisedEvent {
uint64_t timestamp;
uint32_t pixelId : 24;
uint8_t source;
uint32_t pixelId;
// inline NormalisedEvent(uint64_t timestamp, uint8_t source, uint32_t
// pixelId)
@@ -96,6 +96,9 @@ struct __attribute__((__packed__)) NormalisedEvent {
#define P_RateString "RATE%d"
#define P_ClearCountsString "C_%d"
#define P_UdpQueueHighWaterMarkString "UDP"
#define P_SortedQueueHighWaterMarkString "SORT"
/*******************************************************************************
* Stream Generator Coordinating Class
*/
@@ -110,9 +113,11 @@ class asynStreamGeneratorDriver : public asynPortDriver {
const int kafkaMaxPacketSize);
virtual ~asynStreamGeneratorDriver();
virtual asynStatus readInt32(asynUser *pasynUser, epicsInt32 *value);
virtual asynStatus writeInt32(asynUser *pasynUser, epicsInt32 value);
void receiveUDP();
void partialSortEvents();
void processEvents();
void produceMonitor();
void produceDetector();
@@ -133,6 +138,10 @@ class asynStreamGeneratorDriver : public asynPortDriver {
int *P_Rates;
int *P_ClearCounts;
// System Status Parameter Identifying IDs
int P_UdpQueueHighWaterMark;
int P_SortedQueueHighWaterMark;
private:
asynUser *pasynUDPUser;
epicsEventId pausedEventId;
@@ -142,6 +151,7 @@ class asynStreamGeneratorDriver : public asynPortDriver {
const int kafkaMaxPacketSize;
epicsRingBytesId udpQueue;
epicsRingBytesId sortedQueue;
epicsRingBytesId monitorQueue;
rd_kafka_t *monitorProducer;