在Linux上使用阻塞套接字时,除了中断但部分成功的send()系统调用之外,send()是否有任何理由返回少于请求的内容?
我知道这可能是非常实现的定义,并且即使没有任何已安装的信号处理程序依赖于该行为也可能是非常危险的(因此中断系统调用的原因).我可能会绕发送电话直到完成;但是,如果有关于此事的任何官方消息,我将能够避免这种情况.
Why is it assumed that send may return with less than requested data transmitted on a blocking socket?提出了同样的问题,结果不确定:中断的系统调用被提及作为短返回计数的示例,但是仍然不清楚完整的TCP发送缓冲区是否会导致部分发送,或者send()是否会阻塞直到有缓冲区有足够的空间.最佳答案通常,如果发送缓冲区包含一些空间,但对于整个发送请求来说还不够,那么它将尽可能多地发送,然后返回实际添加到缓冲区的数量 – 一个简短的写入.
现在你可以争辩说阻塞(在阻塞套接字上)更有意义,但它不是历史的原因 – TCP基于UNIX管道,这就是UNIX管道的工作方式.主要原因是它使得极端情况(在内核中)更容易 – 你不必担心在做某事的过程中阻塞系统调用;它要么做某事并立即返回,要么什么也不做,并阻塞直到某个事件(此时内核从头开始重试).如果有人尝试在单次写入中写入超过最大缓冲区大小(否则可能导致死锁),您不必担心会发生什么.
@H_301_14@ 总结以上是内存溢出为你收集整理的linux – send()什么时候会返回小于length的参数?全部内容,希望文章能够帮你解决linux – send()什么时候会返回小于length的参数?所遇到的程序开发问题。
如果觉得内存溢出网站内容还不错,欢迎将内存溢出网站推荐给程序员好友。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)