python - 替代扭曲中的 while 循环，不会阻塞 react 器线程

Question

我正在用 Twisted 制作一个聊天应用程序。假设我的服务器的设计方式是，每当它检测到客户端在线时，它都会向客户端发送所有待处理消息(该客户端的那些消息由于离线而缓存在服务器上的 python 列表中)一-在 while 循环中逐一，直到列表耗尽。像这样的事情:

class MyChat(LineReceiver):

    def connectionMade(self):
        self.factory.clients.append(self)

        while True: 
            #retrieve first message from a list of pending-messages(queue) of "self" 
            msg = self.retrieveFromQueue(self)      
            if msg != "empty":
                self.transport.write(msg)       
            else:
                break

    def lineReceived(self, line):
    ...

    def connectionLost(self, reason):
    ...  

    def retrieveFromQueue(self, who):
        msglist = []                                                        

        if who in self.factory.userMessages:
            msglist = self.factory.userMessages[who]

        if msglist != []:
            msg = msglist.pop(0)              #msglist is a list of strings

            self.factory.userMessages[self] = msglist               

            return msg
        else:
            return "empty"  


    factory.userMessages = {}   #dict of list of incoming messages of users who aren't online

因此，根据我对 Twisted 的理解，while 循环将阻塞主 react 器线程，并且任何其他客户端与服务器的任何交互都不会被服务器注册。如果是这种情况，我想要这种方法的替代代码/方法，它不会阻塞扭曲的线程。

更新:由于应用的性质，每个用户可能有 2000-3000 条待处理消息。

Answer 1

我认为https://glyph.twistedmatrix.com/2011/11/blocking-vs-running.html解决了这一点。

这里的答案取决于 self.retrieveFromQueue(self) 到底做什么。你暗示它是这样的:

if self.list_of_messages:
    return self.list_of_messages.pop(0)
return b"empty"

如果是这样的话，那么答案就是一回事。另一方面，如果实现更像是:

return self.remote_mq_client.retrieve_queue_item(self.queue_identifier)

那么答案可能完全是另外一回事。但是，请注意，答案似乎取决于 retrieveFromQueue 的实现。

有一个 while 循环并不那么重要。 while 循环反射(reflect)了这样一个事实:(用 Glyph 的话来说)此代码正在完成工作。

您可能认为此循环所代表的工作量太大，无法一次完成所有工作。如果有数亿条排队消息，那么将它们一一复制到连接的发送缓冲区中可能会使用大量的时间和内存。在这种情况下，您可能希望考虑生产者/消费者模式和 its support in Twisted 。这不会使代码减少(或增加)“阻塞”，但会使其一次运行的时间更短。

所以这里要回答的问题实际上是:

• 是否 retrieveFromQueue 阻塞
• 如果它不阻塞，是否会有如此多的排队消息来处理所有消息会导致 connectionMade 运行很长时间，以致其他客户端注意到服务中断