2013-08-12 2 views
34

Pythons beliebte Requests-Bibliothek soll Thread-Safe auf seiner Homepage sein, aber keine weiteren Details angegeben. Wenn ich requests.session() nenne, kann ich dann passieren sicher dieses Objekt mehr Threads wie so:Ist das Session-Objekt aus Pythons Requests-Bibliothek threadsicher?

session = requests.session() 
for i in xrange(thread_count): 
    threading.Thread(
     target=target, 
     args=(session,), 
     kwargs={} 
    ) 

und Anfragen stellt den gleichen Verbindungspool in mehreren Threads verwendet werden?

Wenn ja, ist dies der empfohlene Ansatz, oder sollte jedem Thread ein eigener Verbindungspool zugewiesen werden? (Angenommen, die Gesamtgröße aller einzelnen Verbindungspools summiert sich zu der Größe eines großen Verbindungspools wie oben.) Was sind die Vor- und Nachteile der einzelnen Ansätze?

+0

Haben Sie herausgefunden, welche ist besser? Ich stoße gerade auf die gleiche Frage. Ich habe für jeden Thread eine neue Sitzung geplant, um alle Anfragen in einem einzelnen Verbindungspool nicht zu blockieren. –

+0

@Marcel Wilson Nicht genau. Obwohl ich für eines meiner Projekte, bei dem ich ein Sitzungsobjekt verwendete, um die gleiche URL immer wieder anzufordern, habe ich das gleiche Sitzungsobjekt an alle Threads gesendet. Die Anwendung scheint zu funktionieren, aber ich bin mir immer noch nicht sicher, was der bessere Ansatz ist. Beachten Sie jedoch, dass mein Problem nicht darin bestand, die Verbindungspools zu komprimieren, sondern dass zu viele Verbindungen geöffnet und gleichzeitig zu viele Anfragen gesendet wurden. – dg123

+0

Anfragen werden auf urllib3 erstellt. Die Thread-Sicherheit von Anfragen ist weitgehend auf die Thread-Sicherheit von urllib3 zurückzuführen, für die die Thread-Sicherheit detaillierter diskutiert wird. – selllikesybok

Antwort

17

Nachdem ich die Quelle von requests.session überprüft habe, werde ich sagen, dass das Session-Objekt threadsicher sein kann, abhängig von der Implementierung von CookieJar.

Session.prepare_request liest aus self.cookies und Session.send ruft extract_cookies_to_jar(self.cookies, ...), und das ruft jar.extract_cookies(...) (jarself.cookies in diesem Fall ist).

Die Quelle für Python 2.7's cookielib erwirbt eine Sperre (threading.RLock), während sie das Glas aktualisiert, so dass es scheinbar threadsicher ist. Auf der anderen Seite, die documentation for cookielib sagt nichts über Thread-Sicherheit, also vielleicht sollte diese Funktion nicht abhängig sein?

UPDATE

Wenn Ihre Threads alle Attribute des Sitzungsobjekts wie headers, proxies mutiert, stream usw. oder die mount Methode aufrufen oder die Sitzung mit dem with Anweisung usw., dann ist es nicht fadensicher.