I am trying to prevent that, since that would mean the data will need to be retained at the 'sender' side of things and i have to keep an eye on that myself. Putting the data in the Queue, means that once it's in there i can do whatever i want with the source within the main thread.
It is a bit of a conundrum, i would want to copy directly to the Queue but both fields of the struct individually, and i just can't think of a way to do that.
The whole thing will be partly blocking in nature i guess.
Firstly i intend to add a 1 field Queue for the filename.
I send the Filename, and then send an empty string to the same Queue, which will hold the thread until at least the filename has been read, Then i send another empty string which holding the main thread again, giving a chance to the receiving task to send back any error codes it may have encountered. Only after these have been sent (if any) will the first empty string be received (and straight away the 2nd empty string) and will the main tread continue.
The file will be opened for WRITE, and anything in the Block Queue will be written to it until the Queue is empty and the file will be closed. As long as there is nothing in the Filename Queue, the moment that anything is found in the Block Queue will be appended to the file which name it has, if any errors are encountered they will be sent to the Error Queue which should periodically be read, although no infinite wait for available space in that is required i guess.
The extra block in the receiving task doesn't really matter all that much, that sort of is part of the buffering, and does add to the Queue, be it only locally.
The goal is to not hold the main thread with the SD writing process and let it continue with the data reception (UDP packets usually) or generation
If the receiving task finds that Queue available, it will read it,
The length will always vary or i will anyway have to maintain whatever leftover bytes there are in a variable, i guess there is no 2 ways about it really. Thank you for your help.