This is mostly an observation at this point. I built in an implicit fillbuf() and protocol_input() if you are reading and see a timeout, even if there is no read flag. This seems to have worked well so far for read operations, but I have come across a case (RFDdiag) where I would like to associate a timeout with a write operation and would prefer not to interfere with the reads.
Is there a documented case where select() does not see read ready but read() will return data? If not, there is no point in this extra read. The thought behind it was that the read() would return whatever was in the input buffer, even if it didn't meet the vmin requirement, but I should develop tests to verify that behavior.
Alternately, perhaps the timeout could be selectively masked by operation.
This is mostly an observation at this point. I built in an implicit fillbuf() and protocol_input() if you are reading and see a timeout, even if there is no read flag. This seems to have worked well so far for read operations, but I have come across a case (RFDdiag) where I would like to associate a timeout with a write operation and would prefer not to interfere with the reads.
Is there a documented case where select() does not see read ready but read() will return data? If not, there is no point in this extra read. The thought behind it was that the read() would return whatever was in the input buffer, even if it didn't meet the vmin requirement, but I should develop tests to verify that behavior.
Alternately, perhaps the timeout could be selectively masked by operation.