一些读取后选择挂起 [英] Select hangs after some reads

问题描述

我正在构建一个多线程应用程序，我遇到了一个很小的问题。我使用select来等待从

套接字读取数据，在一些读取之后，select只是阻塞并保持这种状态

直到我关闭连接插座的另一侧。当

套接字在作者端关闭时，选择版本然后我得到

只有来自套接字的空字符串。

我的问题是这个：它为什么阻止？阅读从未结束，

每次测试我都会向套接字写入50个请求（哪些是字符串）

我已经读取了最多34个请求。我正在使用winPdb来仔细查看发生了什么，我看到线程被阻止在这个
相同的选择。如果我通过套接字发送更多内容，则选择

发布一个帖子，尽管其他数据仍然未读。


这是选择：

rd，w，e = select.select（[self.rfd]，[]，[]）


self.rfd是文件名来自套接字对象的makefile返回的文件对象

方法。

我知道这是一些缓冲行为我不知道但是我不知道不知道

它是什么。


任何东西都有帮助，如果我想要愚蠢你可以说出来。

谢谢

解决方案

al ********** @ gmail.com 写道：

我正在构建一个多线程应用程序我遇到了一个很小的问题。我使用select来等待从
套接字读取数据，在一些读取之后，select只是阻塞并保持这种状态
直到我关闭套接字另一端的连接。当
套接字在编写器端关闭时，选择版本然后我只从套接字中获取空字符串。


这是预期的：第一次返回零长度字符串来自

socket.read（）表示文件结束。 />
我的问题是：它为什么阻止？阅读从未结束，
每次测试我都会向套接字写入50个请求（哪些是字符串）
并且我已经读取了最多34个请求。我正在使用winPdb来仔细查看正在发生的事情，我看到线程被阻止了。
同样选择。如果我通过套接字发送任何更多内容，则为线程选择
版本，尽管其他数据仍未读取。

您确定收到的数据是否以块的形式呈现尺寸

发送给谁？在TCP套接字上不能保证这一点，

并且可能是多个发送被合并为单个

读取。需要关注的重点是发送的总字节数

和收到的。

这是选择：
rd，w，e = select.select （[self.rfd]，[]，[]）

self.rfd是套接字对象中makefile
方法返回的文件对象的fileno。

直接使用套接字的.fileno（）方法结果

会更简单。

我知道这是一些缓冲行为我很想念，但我不知道它是什么。

任何事情都有帮助，如果我想要愚蠢你可以说出来。
谢谢

如果不能看到你的所有代码，很难说你是否在做一些愚蠢的事情，但你给人的印象是

能力。


问候

Steve

-

Steve Holden [phone] [phone]

Holden Web LLC / Ltd http://www.holdenweb.com

爱我，爱我的博客 http://holdenweb.blogspot.com

最近的Ramblings http://del.icio.us/steve.holden

< blockquote>

Steve Holden写道：

al *** *******@gmail.com 写道：

我正在构建一个多线程应用程序，我遇到了一个小小的<和恼人的问题。我使用select来等待从
套接字读取数据，在一些读取之后，select只是阻塞并保持这种状态
直到我关闭套接字另一端的连接。当
套接字在编写器端关闭时，选择版本然后我只从套接字中获取空字符串。
这是预期的：第一次返回零 - 来自
的长度字符串socket.read（）表示文件结束。

我的问题是：为什么阻止？阅读从未结束，
每次测试我都会向套接字写入50个请求（哪些是字符串）
并且我已经读取了最多34个请求。我正在使用winPdb来仔细查看正在发生的事情，我看到线程被阻止了。
同样选择。如果我通过套接字发送更多内容，则选择
发布一个线程，尽管其他数据仍未读取。

您确定收到的数据是否以块的形式呈现
正在发送？在TCP套接字上无法保证这一点，并且可能是多个发送被合并为一个单独的读取。重点关注的重点是发送和接收的总字节数。

好​​吧，实际上我使用的是一个非常简单的协议，它只发送

字符串以换行符结尾。我需要发送3个大块的信息和一个

换行符。在读者方面，我制作了3个readline（），这样我就可以不用关心这个问题了，但也许这就是我在哪里？b
$ b 。如果是这样的话，我将不得不使用更复杂的

协议。

这是选择：
rd，w ，e = select.select（[self.rfd]，[]，[]）

self.rfd是套接字对象中makefile
方法返回的文件对象的fileno 。
直接使用套接字的.fileno（）方法的结果会更简单。

是的，你是对的，这是从旧观念中重新出现的东西。

我知道'有些缓冲行为我不知道但是我不知道
任何事情都有帮助，如果我想要愚蠢你就可以说出来。
谢谢

无法看到你所有的代码很难说你是否正在做一些愚蠢的事情，但你给人一种
能力的总体印象。

谢谢，代码有一个意义nt size现在，如果我不解决它

我会发布最重要的部分。


再次感谢，


Andre LS Meirelles表示
Steve
-
Steve Holden [phone] [phone]
Holden Web LLC / Ltd http://www.holdenweb.com
爱我，爱我的博客 http://holdenweb.blogspot.com
最近的Ramblings http://del.icio.us/steve.holden

2006-06-08， al ******** **@gmail.com < al ********** @ gmail.com>写道：

好吧，实际上我正在使用一个非常简单的协议，它只发送由换行符结束的字符串。我需要发送3个大块的信息和一个
换行符。在读者方面，我制作了3个readline（），这样我就不必关心这个问题了，但也许这就是我摔倒的地方。如果是这种情况，我将不得不使用更复杂的协议。

你不能使用readline（）和select（ ）。 Select告诉你

底层套接字上调用的recv（）是否会阻塞或者不是
。可能发生的是所有数据都已从底层套接字中读取，并且被保存在

缓冲区中，等待readline（）读取。


选择呼叫无法知道缓冲数据。

就其而言，没有剩下的数据了阅读，所以

它会一直阻塞，直到套接字关闭。


-

格兰特爱德华兹格兰特哇！我的意思是土豆

现场......

visi.com

Hi,

I''m building a multithreaded application and I encountered a tiny and
annoying problem. I use a select to wait for data to be read from a
socket, after some reads, the select simply blocks and stays that way
until I close the connection on the other side of the socket. When the
socket is closed on the writer end the select releases and then I get
only empty strings from the socket.
My question is this: Why did it block? The reading has never ended,
every test I make I write 50 requests (wich are strings) to the socket
and I have read the maximum of 34 requests. I''m using winPdb to take a
closer look on what''s happening and I see the threads blocked on this
same select. If I send anything more through the socket, the select
releases for a thread, despite the other data that is still unread.

This is the select:
rd,w,e = select.select([self.rfd],[],[])

self.rfd is the fileno of the file object returned by the makefile
method from the socket object.

I know that''s some buffer behavior that I''m missing but I don''t know
what it is.

anything is helpfull, If I''m beeing stupid you can say it.
thanks

解决方案

al**********@gmail.com wrote:

Hi,

I''m building a multithreaded application and I encountered a tiny and
annoying problem. I use a select to wait for data to be read from a
socket, after some reads, the select simply blocks and stays that way
until I close the connection on the other side of the socket. When the
socket is closed on the writer end the select releases and then I get
only empty strings from the socket.
That''s to be expected: the first return of a zero-length string from
socket.read() indicates end of file.
My question is this: Why did it block? The reading has never ended,
every test I make I write 50 requests (wich are strings) to the socket
and I have read the maximum of 34 requests. I''m using winPdb to take a
closer look on what''s happening and I see the threads blocked on this
same select. If I send anything more through the socket, the select
releases for a thread, despite the other data that is still unread.
Are you sure that the received data is presenting in block the same size
as are being sent? There''s no guarantee this will be so on a TCP socket,
and it may be that multiple sends are being coalesced into a single
read. The important thing to focus on is the total number of bytes sent
and received.
This is the select:
rd,w,e = select.select([self.rfd],[],[])

self.rfd is the fileno of the file object returned by the makefile
method from the socket object.
It would be simpler to use the result of the socket''s .fileno() method
directly.
I know that''s some buffer behavior that I''m missing but I don''t know
what it is.

anything is helpfull, If I''m beeing stupid you can say it.
thanks

Without being able to see all your code it''s hard to say whether or not
you are doing something daft, but you give a general impression of
competence.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Love me, love my blog http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Steve Holden wrote:

al**********@gmail.com wrote:

Hi,

I''m building a multithreaded application and I encountered a tiny and
annoying problem. I use a select to wait for data to be read from a
socket, after some reads, the select simply blocks and stays that way
until I close the connection on the other side of the socket. When the
socket is closed on the writer end the select releases and then I get
only empty strings from the socket.
That''s to be expected: the first return of a zero-length string from
socket.read() indicates end of file.

My question is this: Why did it block? The reading has never ended,
every test I make I write 50 requests (wich are strings) to the socket
and I have read the maximum of 34 requests. I''m using winPdb to take a
closer look on what''s happening and I see the threads blocked on this
same select. If I send anything more through the socket, the select
releases for a thread, despite the other data that is still unread.

Are you sure that the received data is presenting in block the same size
as are being sent? There''s no guarantee this will be so on a TCP socket,
and it may be that multiple sends are being coalesced into a single
read. The important thing to focus on is the total number of bytes sent
and received.

Well, actually I′m using a very simple protocol wich sends only
strings ended by newline. I need to send 3 chunks of information and a
newline after them. On the reader side I make 3 readline(), this way I
wouldn′t have to care about this problem, but maybe that′s where I′m
falling. If that′s the case, I′ll have to use a more complex
protocol.

This is the select:
rd,w,e = select.select([self.rfd],[],[])

self.rfd is the fileno of the file object returned by the makefile
method from the socket object.
It would be simpler to use the result of the socket''s .fileno() method
directly.

Yes, you are right, this is something remanescent from old ideas.

I know that''s some buffer behavior that I''m missing but I don''t know
what it is.

anything is helpfull, If I''m beeing stupid you can say it.
thanks

Without being able to see all your code it''s hard to say whether or not
you are doing something daft, but you give a general impression of
competence.

Thanks, the code has a significant size now, if I don′t solve it
quickly I′ll post the most important parts.

thanks again,

Andre LS Meirelles regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Love me, love my blog http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

On 2006-06-08, al**********@gmail.com <al**********@gmail.com> wrote:

Well, actually I′m using a very simple protocol wich sends only
strings ended by newline. I need to send 3 chunks of information and a
newline after them. On the reader side I make 3 readline(), this way I
wouldn′t have to care about this problem, but maybe that′s where I′m
falling. If that′s the case, I′ll have to use a more complex
protocol.

You can''t use readline() with select(). Select tells you
whether recv() called on the underlying socket will block or
not. What''s probably happening is that all of the data has
been read from the underlying socket and is being held in a
buffer waiting to be read by readline().

The Select call has no way of knowing about that buffered data.
As far as it''s concerned there''s no more data left to read, so
it block until the socket is closed.

--
Grant Edwards grante Yow! My mind is a potato
at field...
visi.com

这篇关于一些读取后选择挂起的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！