summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/CodeGen/PostRASchedulerList.cpp
diff options
context:
space:
mode:
authorsobomax <sobomax@FreeBSD.org>2011-06-04 16:01:30 +0000
committersobomax <sobomax@FreeBSD.org>2011-06-04 16:01:30 +0000
commit0198596495fac56882a6150a2fb3410913bfa861 (patch)
tree5858642c6db2f5312ee1bc7fd93ead571034cfcf /contrib/llvm/lib/CodeGen/PostRASchedulerList.cpp
parente7c4c6498c9a2f7d5d0a00b8a2b03c27e795c3e4 (diff)
downloadFreeBSD-src-0198596495fac56882a6150a2fb3410913bfa861.zip
FreeBSD-src-0198596495fac56882a6150a2fb3410913bfa861.tar.gz
Read from the socket using the same max buffer size as we use while
sending. What happens otherwise is that the sender splits all the traffic into 32k chunks, while the receiver is waiting for the whole packet. Then for a certain packet sizes, particularly 66607 bytes in my case, the communication stucks to secondary is expecting to read one chunk of 66607 bytes, while primary is sending two chunks of 32768 bytes and third chunk of 1071. Probably due to TCP windowing and buffering the final chunk gets stuck somewhere, so neither server not client can make any progress. This patch also protect from short reads, as according to the manual page there are some cases when MSG_WAITALL can give less data than expected. MFC after: 3 days
Diffstat (limited to 'contrib/llvm/lib/CodeGen/PostRASchedulerList.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud