Event driven compared to caller using return value

Question

I have a program written in C and I'm pondering on how to design a part of it.

No C++ here, the existing code is C and so this part must also be C.

Basically, I have a file which splits up and combines parts of data for transmission. I'm just working on the receive part of the code.

It works like this: If you send it data which wasn't split up because it was small enough (but the caller wasn't to know that yet) the function simply returns DATA_AVAILABLE so the caller can call GetData()

However, if you send a chunk of data, the function would return PARTIAL_PACKET, and the caller would have to keep sending data until the function returned DATA_AVAILABLE, so the caller can call GetData() to get the fully reassembled data.

QUESTION: Is this the best way to do it, or should I apply some kind of event system. Eg. the caller does something like "SetOnDataReceived(&processData)" and then just feeds data to the function, not caring about the result code, knowing that the function "processData" will be called once valid data has been received.

Answer 1

Perhaps you could implement a thread to maintain a 'ring-buffer'. The thread would listen for incoming data, and store the data in the buffer. The thread could also parse the data received to delineate when each packet has been fully received.

Then, perhaps your code could offer a suite of functions to the caller. Such as:

/* Initialize your ring-buffer, and start listening for packets, etc. */
int STEVE_Initialize();

/* Returns the number of fully recieved packets ready for processing. */
int STEVE_PacketsReadyCount();

/* Read a full packet from the ring-buffer and return it to the caller. */
int STEVE_FetchNextPacket();

/* Stop listening for packets, free ring-buffer, etc. */
int STEVE_Terminate();

POLL METHOD Given such an implementation, the caller can use 'Steve_PacketsReadyCount()' to implement a polling loop. When a packet is ready, the caller would call 'STEVE_FetchNextPacket()' to obtain the next full packet (at which time, it would be removed from the ring-buffer).

SIGNAL METHOD A more elaborate implementation might be to use system signals, such as the USR1 signal, to signal the caller that a full packet is ready. The caller would alerted to the complete arrival of a full packet from a caller-implemented signal handler.

SEMAPHORE METHOD Perhaps your code could provide a semaphore to the client that could be used by the client to "sleep" until a full packet arrives.

There are many more methods that might be used, including some sort of a message queue implementation. However it is designed, perhaps the most important input to the architecture is "what would be easiest for the caller". In order to more fully answer your question, more detail about the needs of the caller are required.