When using Socket::isPending with 'timeout'!=0 in a PosixThread with a scheduled alarm (setTimer(timeout2)), Socket::isPending will wait for data on the Socket to become available longer than expected, because of Socket::isPending restarting a poll on the filehandle with the original 'timeout' again.
Of course the ALRM has to be delivered while the Socket called poll on it's filehandle (otherwise everything will be fine). But this is very likely to happen if timeout2 < timeout.
While waiting longer than expected in isPending may be inconvient but not fatal..consider this possible 'deadlock':
Using a PosixThread that's resetting the timer via PosixThread::setTimer(timeout_t t1) in it's OnTimeout handler. Assume Socket::isPending(SOCKET_PENDING_XYZ, t2) is in effect while a SIGALRM is delivered. Further assume that the Socket will never receive any data (common assumption - otherwise you wouldn't set a timeout):
- PosixThread::OnTimeout will be called which installes a new timer with a timeout of t1
- Socket::isPending will restart it's poll call because of errno==EINTR. Socket::isPending will restart poll with the _original_ timeout t2.
...and now.... assume: t1 < t2! Bingo! Socket::isPending will never return!
so what's the message? never reinstall the timer in OnTimer?? I don't think so... probably it'd be best if isPending would care to restart the poll with an updated timeout.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using Socket::isPending with 'timeout'!=0 in a PosixThread with a scheduled alarm (setTimer(timeout2)), Socket::isPending will wait for data on the Socket to become available longer than expected, because of Socket::isPending restarting a poll on the filehandle with the original 'timeout' again.
Of course the ALRM has to be delivered while the Socket called poll on it's filehandle (otherwise everything will be fine). But this is very likely to happen if timeout2 < timeout.
While waiting longer than expected in isPending may be inconvient but not fatal..consider this possible 'deadlock':
Using a PosixThread that's resetting the timer via PosixThread::setTimer(timeout_t t1) in it's OnTimeout handler. Assume Socket::isPending(SOCKET_PENDING_XYZ, t2) is in effect while a SIGALRM is delivered. Further assume that the Socket will never receive any data (common assumption - otherwise you wouldn't set a timeout):
- PosixThread::OnTimeout will be called which installes a new timer with a timeout of t1
- Socket::isPending will restart it's poll call because of errno==EINTR. Socket::isPending will restart poll with the _original_ timeout t2.
...and now.... assume: t1 < t2! Bingo! Socket::isPending will never return!
so what's the message? never reinstall the timer in OnTimer?? I don't think so... probably it'd be best if isPending would care to restart the poll with an updated timeout.