C++ Boost Asio Serial Port Synchronous read_some Blocking Indefinitely? - c++

Question

I'm trying to implement my own synchronous, serial port "read_until" function but with a timeout. My implementation looks a bit like this in pseudo-code:
//returns true if timed out, otherwise false
bool MyReadUntil(string delim, int timeoutSecs)
{
//set up timer
time start = now();
time current = now();
time deltaTime = start - current;
//keep appending to this string until timer runs out
string readString = "";
char[1024] cBuff;
boost::system::error_code ec;
while(readString.find(delim) == string::npos)
{
//update time and return true if timed out
current = now();
deltaTime = start-current;
if (deltaTime>=timeoutSecs)
{
return true;
}
else
{
//this only works once
//NOTE: serialPort is a pointer to a boost::asio::serial_port
serialPort->read_some(boost::asio::buffer(cBuff), ec);
if (!ec)
{
readString = readString + cBuff;
}
}
}
//if we break the while loop no timeout
return false;
}
So what happens is that the read_some function only reads once on the first iteration of the loop, and then the next time it is called it blocks forever. I tried looking up the answer and have been searching for a while, but unfortunately the terms "read_some" and "async_read_some" are very closely related, and, seeing as how the asynchronous functionality is more commonly used, the latter dominates my search queries, making it hard to find an answer so far.
I would like to avoid putting in an async_read for this, because this is just part of a handshake implementation for a usb-protocol. It doesn't need to be more complicated by being made asynchronous (there's nothing for it to do in the interim but wait anyway).
I think the issue has something to do with resetting the serial port on every read or something along those lines (I remember reading an article about the proper time to reset when iteratively reading from a serial port, but I can't find it again unfortunately). In any case, I don't think it's something earth-shatteringly complicated to fix, but I'm having difficulty finding the answer. Thanks in advnce for your help.

Answer 1

Ok, so because of some suggestions I received, I found that only one byte of data was being read on that first loop, and then no more data was being read subsequently. This behavior though was not unwarranted, because boost was doing exactly what it was supposed to be doing. which is
"block[ing] until one or more bytes of data has been read successfully"
The answer was not that there was an error being thrown, but because I had assumed there was data being transmitted when in fact no data was coming over the wire (though, I'm still not entirely clear on where the one lone byte was coming from on the first iteration of the read). I traced the issue back and found a hardware bug causing the issue, so, once that was fixed, and data was being transmitted properly, it stopped blocking. Can't believe that slipped my mind, but thanks for the suggestions everybody.