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

[Claudio Freire]

2015-01-05 20:42 GMT-03:00 Roberto Alsina <ralsina en netmanagers.com.ar>:
> On 05/01/15 20:37, Claudio Freire wrote:
>>
>> 2015-01-05 20:30 GMT-03:00 Andres Riancho <andres.riancho en gmail.com>:
>>>
>>> Alejandro,
>>>
>>> On Mon, Jan 5, 2015 at 7:36 PM, Alejandro Santos <listas en alejolp.com>
>>> wrote:
>>>>
>>>> 2015-01-05 20:58 GMT+01:00 Andres Riancho <andres.riancho en gmail.com>:
>>>>>
>>>>>      La pregunta entonces es... que otras soluciones tengo a este
>>>>> problema?
>>>>>
>>>> import multiprocessing
>>>> import time
>>>>
>>>> def exec_with_timeout(f, args, timeout):
>>>>      p = multiprocessing.Process(target=f, args=args)
>>>>      p.start()
>>>>      p.join(timeout)
>>>>      if p.is_alive():
>>>>          p.terminate()
>>>>
>>>> def bad_func(t):
>>>>      while True:
>>>>          time.sleep(t)
>>>>
>>>> exec_with_timeout(bad_func, (5.0, ), 0.1)
>>>
>>>      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.
>>
>>
>> Podés intentar lo mismo con threading.Thread en vez de
>> multiprocessing.Process.
>
>
> El problema es que matar threads no es una ciencia exacta.

Si, bueno, habría que quitar el terminate y dejarlo corriendo.

De hecho, imagino que alguna razón para llamar a la librería habrá, y
alguna razón por la que tarda habrá, y otra razón por la que no hace
falta esperar el resultado habrá, pero que dejar que la librería
termine de hacer su trabajo es también imagino un requerimiento.