[pyar] Timeouts para codigo de terceras partes: PyThreadState_SetAsyncExc?

[Roberto Alsina]

On 06/01/15 15:04, Andres Riancho wrote:
> Alejandro,
>
> 2015-01-05 23:49 GMT-03:00 Alejandro Santos <listas en alejolp.com>:
>> 2015-01-06 0:30 GMT+01:00 Andres Riancho <andres.riancho en gmail.com>:
>>>      Gracias por la buena propuesta, despues de enviar el email estuve
>>> viendo eso y creo que en una gran cantidad de casos sirve pero... a mi
>>> no me va a servir ya que la respuesta de la libreria es un objeto que
>>> NO se puede serializar, por lo que no lo puedo pasar entre el
>>> subproceso (multiprocessing.Process) y el proceso principal.
>>>
>>>      Alguna idea de como hacer un workaround de eso? Estuve leyendo un
>>> poco sobre multiprocessing.Namespace, pero no estoy seguro, deberia
>>> probarlo.
>>>
>> ¿Qué es lo que la librería devuelve, un file handle o socket? Contame
>> un poco más en detalle cómo funciona. Lo que podés hacer es mover tu
>> lógica de procesamiento dentro de bad_func.
>>
>> Por ejemplo, si tu librería devuelve un socket que tenés que usar,
>> hacele read y write dentro de bad_func.
> Creo que no funcionaria esto, una de las cosas que estoy queriendo
> pasar de un lado al otro el resultado de parsear HTMLs usando lxml, el
> cual no es pickleable (segun la doc, pruebas, etc.)
>
> Hice algunas pruebas con el Manager.Namespace y tambien tiene el
> requerimiento de que sea pickleable lo que sea que guardes alli, lo
> mismo para Manager.dict y sus amigos.
>

Esto te va a sonar raro, pero lxml te ofrece un método buenísimo para 
serialiar sus objetos. Los puede serializar a XML.
Claro, me vas a decir "pero para salir de eso lo parseé" y tenés razón :-)

Sin embargo: si lo que necesitás son "algunos datos sacados del 
parseado" eso lo podés hacer adentro del subproceso, y después serializarlo.

En general, pasar cosas muy grandes serializadas de un lado a otro es caro.