Urllib2 y Cookielib hilos de seguridad

Por lo que he podido decir, cookielib no es seguro para hilos; Pero, una vez más, la publicación dice que tiene cinco años, por lo que podría estar mal.

Sin embargo, me he estado preguntando: si engendro una clase como esta:

class Acc: jar = cookielib.CookieJar() cookie = urllib2.HTTPCookieProcessor(jar) opener = urllib2.build_opener(cookie) headers = {} def __init__ (self,login,password): self.user = login self.password = password def login(self): return False # Some magic, irrelevant def fetch(self,url): req = urllib2.Request(url,None,self.headers) res = self.opener.open(req) return res.read() 

para cada hilo trabajador, funcionaria? (¿o hay un mejor enfoque?) Cada hilo usaría su propia cuenta; así que el hecho de que los trabajadores no compartan sus cookies no es un problema.

Desea utilizar pycurl (la interfaz de python para libcurl ). Es seguro para subprocesos, admite cookies, https, etc. La interfaz es un poco extraña, pero solo requiere un poco de tiempo para acostumbrarse.

Solo he usado pycurl w / HTTPBasicAuth + SSL, pero encontré un ejemplo usando pycurl y cookies aquí . Creo que necesitarás actualizar el pycurl.COOKIEFILE (línea 74) y pycurl.COOKIEJAR (línea 82) para tener un nombre único (tal vez id(self.crl) de id(self.crl) ).

Como recuerdo, deberás crear un nuevo pycurl.Curl() para cada solicitud para mantener la seguridad de subprocesos.

Podría ver la implementación de la biblioteca [python_install_path]/lib/cookielib.py para asegurarse de que cookielib.CookieJar es seguro para subprocesos .

Esto significa que si compartirá una instancia de CookieJar entre varias conexiones en diferentes subprocesos, no se enfrentará ni siquiera a la lectura inconsistente de Cookie Set, porque CookieJar utiliza lock self._cookies_lock en self._cookies_lock interior.

La misma pregunta que tú. Si no usa pycurl, creo que debe urllib2.install_opener (self.opener) antes de cada urllib2.urlopen.

Tal vez debería usar el pycurl también, urllib2 no es tan inteligente.