2010-09-02 59 views
6

我需要從數百個pop3電子郵件帳戶中提取,並且我想構建一個強大的服務器來執行此操作。扭曲是構建多線程服務器的好選擇嗎?

這種類型的項目會扭曲嗎?

現在一個簡單的原型就是從一個單一的pop3賬戶中提取,然後它會從多個賬戶中提取,但這將是一個序列化的過程。

我想創建一個具有多個線程的服務器,以便它可以同時執行任務。

回答

7

Twisted是一個用Python編寫的事件驅動的網絡框架。它在很大程度上構建了異步和非阻塞功能,並且最好構想開發利用這些功能的網絡應用程序。它支持用於不能提供異步非阻塞I/O的用例。這是基於這樣一個事實,即大部分時間都花在等待網絡I/O操作。

利用這個模型的兩個模型是線程模型,您創建多個線程,每個線程完成單個任務或使用非阻塞I/O通過交錯多個任務完成多個任務的單個進程。 Twisted非常適合第二款機型。

非阻塞模式

+--------------------------+ 
|task1 | wait period | comp| 
+--------------------------+ 
     +--------------------------+ 
     |task2 | wait period | comp| 
     +--------------------------+ 

可以開發出扭曲的一個非常強大的服務器,它具有POP3/IMAP支持。有一個如何構建pop3 client with twisted的例子。

0

這是一個很好的服務器的選擇,但從描述你正在尋找一個多線程的POP客戶端。

Twisted是爲響應傳入請求等事件而做出的,您需要發送請求,所以在這種情況下,我擔心會扭曲爲有限的價值。

+2

根本不是。當涉及到網絡層時,客戶端和服務器並不是完全不同。 – 2010-09-02 19:31:59

2

考慮到大部分POP3活動將成爲網絡I/O,這就是Twisted擅長的地方。你並不像真正的線程那樣執行基於事件的異步套接字操作,這是Twisted的最大榮耀。

所以,是的,扭曲將是這種類型的項目的不錯的選擇。它可以很好地完成客戶端和服務器操作,並且啓動一個新的異步TCP客戶端幾乎是微不足道的,並且它已經有一個默認可用的POP3 TCP Client

-1

扭曲的謹慎之詞,而扭曲非常強大我發現使用文檔中提供的代碼示例旋轉上百個線程是競爭條件和死鎖的祕訣。我的建議是嘗試扭曲,但如果扭曲變得難以管理,stdlib多線程模塊會在機翼中等待。我使用上述圖書館的生產者消費者模式獲得了很好的成功。

+4

涉及到線程時,扭曲既不多也不少於競爭條件。 Twisted最棒的是能夠做很多事情*沒有*線程。實際上,像twisted.internet.threads.deferToThread這樣的幫助者實際上確實會把線程的一小部分痛苦帶走。 ;) – 2010-09-02 19:33:13

+0

這是我指出的模型,我認爲它更容易理解,更易於調試,並且通常比扭曲的問題更少。我並不是想說一個圖書館比另一個圖書館更好。我同意扭曲的技術優點是優越的,但這不是使用框架的唯一原因。 – ebt 2010-09-02 20:19:35