¿Cómo aplicar retro presión a un canal de salida de Tcl?
Tenemos una aplicación que permite al usuario pasar un bloque de código Tcl arbitrario (como una devolución de llamada) a una API personalizada que lo invoca en elementos individuales de un árbol de datos grande. Para mejorar el rendimiento, esto se hace utilizando un grupo de hilos, por lo que las cosas pueden ser rápidas.
El problema es que no tenemos control sobre el código del usuario y, en un caso, están utilizando un “puts” que hace que la memoria explote y la aplicación se bloquee. Puedo evitar esto redirigiendo stdout a /dev/null, lo que me lleva a creer que los búferes internos de Tcl no se pueden vaciar lo suficientemente rápido, por lo que sigue acumulando búferes. El análisis del montón de memoria parece confirmar esto.
Lo que no entiendo es que no he modificado ninguna de las opciones de stdout, por lo que debería ser en búfer de línea, en bloque, 4k. Entonces, mi primera pregunta sería: ¿por qué está sucediendo esto? ¿No debería haber una retroalimentación aplicada para evitar esto?
Mi segunda pregunta sería: ¿cómo puedo evitar esto? Si el usuario quiere hacer algo incorrecto, estoy más que dispuesto a limitar su rendimiento, pero no quiero que la aplicación se bloquee. Supongo que una solución sería redefinir “puts” para que escriba en un archivo (o simplemente no haga nada) antes de invocar la devolución de llamada, pero estaría interesado si hubiera alguna manera de asegurar una retroalimentación en el canal para evitar que siga acumulando búferes.
¡Gracias por cualquier pensamiento!
davy.ai
Como experto en IT especializado en tcl, aquí están mis pensamientos sobre el problema planteado:
Primera Pregunta:
La razón del fallo podría ser que los buffers internos de Tcl no se están vaciando lo suficientemente rápido y el comando puts está causando que la memoria explote. Es sorprendente que las opciones de stdout no estén evitando que esto ocurra. Dado que el bloque de código es proporcionado por el usuario, es posible que hayan realizado algún cambio en la configuración de stdout desde la configuración por defecto. También podría tratarse de un error en la versión de Tcl que se está utilizando.
Segunda Pregunta:
Una posible solución para evitar el fallo podría ser redefinir puts para escribir en un archivo (o no hacer nada) antes de invocar el callback. Otra solución sería implementar una contrapresión en el canal para evitar que siga almacenando en el buffer. Este enfoque puede implicar ralentizar el conjunto de hilos (thread pool) o limitar el número de callbacks que se pueden ejecutar de manera concurrente. Esto asegurará que haya tiempo suficiente para vaciar los buffers internos de Tcl entre las llamadas sucesivas a puts.
En conclusión, comprender la causa del problema e implementar mecanismos de contrapresión son fundamentales para abordar el problema de la explosión de memoria y los fallos de la aplicación.