¿Habéis visto el Ibex 35...? Abril 2011 +

[ghkghk]

Vamos Pepón llévame al maná!

 

[rafaxl]

Como el ibex es un casino, estaria bien hacer una porra para ver lo que sube y baja, lastima que solo sepa hacerlo con movimientos de casi 3 digitos.

Claca tus 450 estan ahi muriendo, de momento los pasamos.

 

[Mulder]

Exacto, BL... estas ejecuciones pueden ser (y serán!) concurrentes, dado que precisamente un servidor web está pensado para poder hacer spawn (crear) varios hilos y atender varias peticiones simultáneas.

Así que cada vez que pulsabas F5 o "refrescar" en tu navegador, en efecto, lanzabas una copia nueva de tu Missile_Launch_Control.php ::

Una vez descartada la idea del exec con el tema de BL lo que debe pasar es que ha de tener un programa que no finaliza nunca, aun así nunca he visto que eso en PHP se quede funcionando aunque el server lance varios threads por ejecución.

Si fuera ese el tema, el navegador al cargar la página acabaría dando un timeout, creo que el apache está diseñado para 'recoger la cochambre' que ya no se está visualizando, por esa razón creo que lo que le pasa es que tiene una instancia del navegador en marcha aunque el no la esté viendo.

Ha de ser eso o un exec, no es nada sencillo provocar ese error y a mi no me ha ocurrido nunca y eso que hasta he escrito código python que devolvía código HTML y que ejecutaba un programa PHP, es decir, vericuetos de lo más raro y ni aun así me ha ocurrido eso.

 

[banana]

El navegador nunca dará un timeout, porque el navegador no "entiende de barcos", esto es, no sabe (ni quiere saber) que detrás de una petición HTTP hay un *** server-side, escrito en php, perl, C++ o lo que sea.
Un timeout en el navegador sólo puede ser generado por el "tramo" HTTP, y ese tramo es totalmente correcto (ya que la petición llega, se atiende, se lanza el php, etc.).

Lo que sí puede ocurrir es que si el tiempo de ejecución del php de BL supera la directriz php_max_execution_time (ver php.ini) entonces el engine php "corta" y devuelve el control al navegador cliente.
Pero incluso en ese caso, te encontrarás con una pantalla en blanco, nada de errores, ni timeout, etc.

Esto ocurre porque no tiene nada que ver (insisto) un proceso con otro: el navegador es un proceso que lanza el usuario (BL o quien sea), y el programa php es *otro* proceso totalmente independiente (la clave está en esto) que es lanzado por el servidor web, no por el usuario ni por el navegador.

De hecho es muy sencillo provocar el error que está teniendo BL. Basta con hacer un pequeño php con un bucle infinito, que a intervalos de 5 segundos haga un INSERT en una table.

Ejecutalo una vez a través del navegador. Cierra el navegador. Ahora, los insert en la tabla siguen produciéndose "educadamente" cada 5 segundos.

Abre un segundo navegador. Vuelve a lanzar el php. Cierra el navegador.

Ahora tienes dos instancias del php corriento concurrentemente. Inspecciona la base de datos y verás como, cada 5 segundos, hay DOS inserts: uno por cada instancia que sigue funcionando a su bola ( y seguirá haciendolo mientras no supere el php_max_execution_time)

Una vez descartada la idea del exec con el tema de BL lo que debe pasar es que ha de tener un programa que no finaliza nunca, aun así nunca he visto que eso en PHP se quede funcionando aunque el server lance varios threads por ejecución.

Si fuera ese el tema, el navegador al cargar la página acabaría dando un timeout, creo que el apache está diseñado para 'recoger la cochambre' que ya no se está visualizando, por esa razón creo que lo que le pasa es que tiene una instancia del navegador en marcha aunque el no la esté viendo.

Ha de ser eso o un exec, no es nada sencillo provocar ese error y a mi no me ha ocurrido nunca y eso que hasta he escrito código python que devolvía código HTML y que ejecutaba un programa PHP, es decir, vericuetos de lo más raro y ni aun así me ha ocurrido eso.

 

[Benditaliquidez]

Una vez descartada la idea del exec con el tema de BL lo que debe pasar es que ha de tener un programa que no finaliza nunca, aun así nunca he visto que eso en PHP se quede funcionando aunque el server lance varios threads por ejecución.

Si fuera ese el tema, el navegador al cargar la página acabaría dando un timeout, creo que el apache está diseñado para 'recoger la cochambre' que ya no se está visualizando, por esa razón creo que lo que le pasa es que tiene una instancia del navegador en marcha aunque el no la esté viendo.

Ha de ser eso o un exec, no es nada sencillo provocar ese error y a mi no me ha ocurrido nunca y eso que hasta he escrito código python que devolvía código HTML y que ejecutaba un programa PHP, es decir, vericuetos de lo más raro y ni aun así me ha ocurrido eso.

Bueno es que he modificado el php.ini para que no tenga tiempo máximo de ejecución y también he aumentado la memoria que puede utilizar cada proceso.

Que no tengo al navegador enganchado por ahí en background con el proceso corriendo te lo digo yo porque he utilizado programas para buscar y cancelar procesos y no aparece nada.

Creo que es lo que dice banana, es el Apache el que lo está ejecutando, lo que no sé es por qué el Apache no tiene una especie de administrador de tareas para poder verlo.

¿De manera que cualquier proceso infinito que lances se queda ejecutándose en el Apache p'a los restos?

Pues qué bien, le tendré que poner alguna condición para detenerlo, que lea alguna variable en algún archivo o algo así, ¿se puede hacer así o me dará error de lectura si coincide que tengo ese archivo abierto al modificarlo?

Del Ibex ni hablo porque sigue lo previsto desde ayer, intento de rebote.

Ojo, que mañana no hay POMO, el viernes no hay bolsa ni en WS ni aquí y el lunes no abre el Ibex.

 

[rafaxl]

Atpc los 450 como queso de untar. Y a este paso los 500 tambien.

El Dax... sin comentarios.

Ya tocaba subida por encima del punto porcentual. Me piro con la bici, que para ver lo de siempre mejor tomo el aire y el sol.

El vencimiento es mañana no??

 

[banana]

Bueno es que he modificado el php.ini para que no tenga tiempo máximo de ejecución....
....
¿De manera que cualquier proceso infinito que lances se queda ejecutándose en el Apache p'a los restos?

Eres un jachondo, BL ::... primero desactivas voluntariamente el fail-safe contra bucles infinitos, y luego te llevas las manos a la cabeza :XX::XX:

Creo que es lo que dice banana, es el Apache el que lo está ejecutando, lo que no sé es por qué el Apache no tiene una especie de administrador de tareas para poder verlo.

Técnicamente no es una "tarea del apache", sino un hilo (thread) de apache por derecho propio, totalmente independiente del resto de hilos (y del hilo raíz, de paso). Lo más parecido a lo que estás buscando es una lista de hilos (procesos) apache corriendo en tu máquina actual... y aún así, te quedaría el problema de identificar qué están haciendo esos hilos, cosa imposible de ver desde, por ejemplo (si fuera linux ) un

"ps aux | grep httpd"

ya que eso te dará una lista de hilos apache, pero no lo que están haciendo.

Cuando apache hace un spawn y crea un hilo "descendiente" (bien sea para servir un perversos HTML o para lanzar un complejísimo programa server-side, da igual, se crea el hilo igualmente) digamos que se "pierde" el control sobre él definitivamente.

de ahí puedes sacar la conclusión de que programas que requieran cierto control o interactividad una vez lanzados, es mala idea lanzarlos a través de web. El detach, es lo que tiene ::

 

[Mulder]

Bueno es que he modificado el php.ini para que no tenga tiempo máximo de ejecución y también he aumentado la memoria que puede utilizar cada proceso.

Que no tengo al navegador enganchado por ahí en background con el proceso corriendo te lo digo yo porque he utilizado programas para buscar y cancelar procesos y no aparece nada.

Creo que es lo que dice banana, es el Apache el que lo está ejecutando, lo que no sé es por qué el Apache no tiene una especie de administrador de tareas para poder verlo.

¿De manera que cualquier proceso infinito que lances se queda ejecutándose en el Apache p'a los restos?

Pues qué bien, le tendré que poner alguna condición para detenerlo, que lea alguna variable en algún archivo o algo así, ¿se puede hacer así o me dará error de lectura si coincide que tengo ese archivo abierto al modificarlo?

Del Ibex ni hablo porque sigue lo previsto desde ayer, intento de rebote.

Ojo, que mañana no hay POMO, el viernes no hay bolsa ni en WS ni aquí y el lunes no abre el Ibex.

jejeje, nunca se me ocurrió hacer ese tipo de 'banana' 😀

Es que no tiene sentido modificar php.ini salvo que quieras cosas muy concretas y no haya otro modo de hacerlas (y creo que no es el caso, igual que los goto), tu programa ha de cumplir con unos parámetros estándar y hay que ceñirse lo mejor posible a lo que hay porque los que hicieron php ya tuvieron en cuenta todo tipo de casos, por motivos de migración de un servidor a otro, por ejemplo.

De todas formas sigo pensando que el navegador debería dar un timeout ya que el programa PHP no finaliza nunca, aunque esto puede que solo sea aplicable a la parte que se visualiza y como el insert no se ve pues ahí está el problema.

El caso es que es lo mismo que los GOTO, siempre hay una forma más elegante y más lógica de programar, incluso aunque sea usando un bucle infinito y generando una señal para salirse de el. Algún día tendrás que cambiar tu sistema o tendrás que reinstalarlo, o te olvidarás del código y al cabo de unos años volverás a leerlo, si todo está programado de forma sucia, rápida y a base de incompatibildiades tendrás un buen lio el día que quieras 'rescatar' ese código.

 

[atman]

Titular en eleconomista.com: "Los alcistas no se atreven con los 10.500." 🙂

...o narran el partido en directo... o cambian la forma de hacer títulos o... no sé... pero es que siempre les pasa lo mismo...

 

[Benditaliquidez]

Eres un jachondo, BL ::... primero desactivas voluntariamente el fail-safe contra bucles infinitos, y luego te llevas las manos a la cabeza :XX::XX:



Técnicamente no es una "tarea del apache", sino un hilo (thread) de apache por derecho propio, totalmente independiente del resto de hilos (y del hilo raíz, de paso). Lo más parecido a lo que estás buscando es una lista de hilos (procesos) apache corriendo en tu máquina actual... y aún así, te quedaría el problema de identificar qué están haciendo esos hilos, cosa imposible de ver desde, por ejemplo (si fuera linux ) un

"ps aux | grep httpd"

ya que eso te dará una lista de hilos apache, pero no lo que están haciendo.

Cuando apache hace un spawn y crea un hilo "descendiente" (bien sea para servir un perversos HTML o para lanzar un complejísimo programa server-side, da igual, se crea el hilo igualmente) digamos que se "pierde" el control sobre él definitivamente.

de ahí puedes sacar la conclusión de que programas que requieran cierto control o interactividad una vez lanzados, es mala idea lanzarlos a través de web. El detach, es lo que tiene ::

Coñe, es que si no hacía un bucle infinito no me servía de nada, lo que pasa es que yo pensaba que desde el navegador, de la misma manera que lanzas el proceso, lo detenías al desconectarte, pero ya veo que el php es un tanque suicida.

Como última medida para no mandarlo todo atp, ¿alguna idea para controlar ese s-c-r-i-p-t remotamente, es buena idea lo que he dicho en el post anterior?

 

[Pepitoria]

el dax por encima de los 7200

 

[Mulder]

Coñe, es que si no hacía un bucle infinito no me servía de nada, lo que pasa es que yo pensaba que desde el navegador, de la misma manera que lanzas el proceso, lo detenías al desconectarte, pero ya veo que el php es un tanque suicida.

Como última medida para no mandarlo todo atp, ¿alguna idea para controlar ese s-c-r-i-p-t remotamente, es buena idea lo que he dicho en el post anterior?

Te sugerí hace tiempo que lo pusieras como una tarea programada, al estilo cron y que se ejecute cada minuto o lo ejecutas al principio de la sesión y que se quede en background hasta que termine el día, con PHPCLI sería bastante sencillo.

Yo lo tengo de esa forma.

 

[Benditaliquidez]

Atpc los 450 como queso de untar. Y a este paso los 500 tambien.

El Dax... sin comentarios.

Ya tocaba subida por encima del punto porcentual. Me piro con la bici, que para ver lo de siempre mejor tomo el aire y el sol.

El vencimiento es mañana no??

¿Qué vencimiento? como no sea de opciones o algo así...

 

[pipoapipo]

un dia bajan mas del 2%, dos dias despues suben mas del 2%......que despiporre

si cierran por estas zonas se cerro el grifo de los cortos..... q vivan los largos !!!!

 

[atman]

el dax por encima de los 7200

...y el Footsie, volvió a los 6.000 y el CAC a punto está de los 4.000. Ola tras ola esto se puede embalar... pero como alguno falle, podemos tener un numero interesante de divergencias...

 

[Benditaliquidez]

jejeje, nunca se me ocurrió hacer ese tipo de 'banana' 😀

Es que no tiene sentido modificar php.ini salvo que quieras cosas muy concretas y no haya otro modo de hacerlas (y creo que no es el caso, igual que los goto), tu programa ha de cumplir con unos parámetros estándar y hay que ceñirse lo mejor posible a lo que hay porque los que hicieron php ya tuvieron en cuenta todo tipo de casos, por motivos de migración de un servidor a otro, por ejemplo.

De todas formas sigo pensando que el navegador debería dar un timeout ya que el programa PHP no finaliza nunca, aunque esto puede que solo sea aplicable a la parte que se visualiza y como el insert no se ve pues ahí está el problema.

El caso es que es lo mismo que los GOTO, siempre hay una forma más elegante y más lógica de programar, incluso aunque sea usando un bucle infinito y generando una señal para salirse de el. Algún día tendrás que cambiar tu sistema o tendrás que reinstalarlo, o te olvidarás del código y al cabo de unos años volverás a leerlo, si todo está programado de forma sucia, rápida y a base de incompatibildiades tendrás un buen lio el día que quieras 'rescatar' ese código.

Ya, ya, lo de los goto era porque había leído que utilizando "case" iba más lento, pero viendo que hablamos de diezmilésimas de segundo cualquiera sabe a qué se refieren con "más lento", le pondré un case para que no venga a por mí el talibán informático...

Pero si una vez que lanzo el php ya no lo puedo controlar supongo que tendré que programar una condición escrita en un archivo que yo sí controle, para que el php se detenga o haga algo distinto cuando yo quiero.

¿Qué forma elegante hay de hacer eso?

 

[bah]

Coñe, es que si no hacía un bucle infinito no me servía de nada, lo que pasa es que yo pensaba que desde el navegador, de la misma manera que lanzas el proceso, lo detenías al desconectarte, pero ya veo que el php es un tanque suicida.

Como última medida para no mandarlo todo atp, ¿alguna idea para controlar ese s-c-r-i-p-t remotamente, es buena idea lo que he dicho en el post anterior?

¿has probado con otro servidor web?

no he leido a fondo :o, pero yo haría un proceso shell php que lo controles manualmente, y el servidor web para mostrar el resultado. esto es independiente del servidor web.

para controlar remotamente... en windows no se, pero el proceso debería guardar un PiD en un archivo.txt, y para cancelar, hacer un kill leyendo el archivo.

 

[pipoapipo]

el DAX ha petado dos resistencias y va hoy a por la tercera......... no hay dos sin tres?

 

[rafaxl]

el DAX ha petado dos resistencias y va hoy a por la tercera......... no hay dos sin tres?

Todo esto es una fruta farsa. Cuando les apetece España es una guano, nos suben el bono a tomar por pandero, nos hunden la bolsa y luego... fuegos artificiales y el bono bajando a todo trapo.

No me creo nada, ni parriba ni pabajo.

 

[Benditaliquidez]

Te sugerí hace tiempo que lo pusieras como una tarea programada, al estilo cron y que se ejecute cada minuto o lo ejecutas al principio de la sesión y que se quede en background hasta que termine el día, con PHPCLI sería bastante sencillo.

Yo lo tengo de esa forma.

Me pareció un poco chapucero hacerlo así... ::::😀

Pregunta de examen, ¿como controlar remotamente un s-c-r-i-p-t php? razone la respuesta. (2,5 pipos)

 

[gamba]

Ya, ya, lo de los goto era porque había leído que utilizando "case" iba más lento, pero viendo que hablamos de diezmilésimas de segundo cualquiera sabe a qué se refieren con "más lento", le pondré un case para que no venga a por mí el talibán informático...

Pero si una vez que lanzo el php ya no lo puedo controlar supongo que tendré que programar una condición escrita en un archivo que yo sí controle, para que el php se detenga o haga algo distinto cuando yo quiero.

¿Qué forma elegante hay de hacer eso?

Lanze y acabe el programa a la hora de apertura y cierre del mercado, si hay lago que al ordenador le sale bien es dar la hora. Y quite TODOS los GOTO!

 

[Mulder]

Ya, ya, lo de los goto era porque había leído que utilizando "case" iba más lento, pero viendo que hablamos de diezmilésimas de segundo cualquiera sabe a qué se refieren con "más lento", le pondré un case para que no venga a por mí el talibán informático...

Pero si una vez que lanzo el php ya no lo puedo controlar supongo que tendré que programar una condición escrita en un archivo que yo sí controle, para que el php se detenga o haga algo distinto cuando yo quiero.

¿Qué forma elegante hay de hacer eso?

Si es PHPCLI no tendrás problema en localizar el proceso, claro que tendrás que hacerlo a mano porque ignoro si hay algo en win que permita cancelar procesos de forma automática (banana supongo que podrá aconsejarte al respecto 😀), en Linux sería bastante sencillo hacerlo.

Creo que desde cygwin, que es una especie de Linux para win, se puede hacer, de todas formas no sería nada complicado decirle al programa que si son las 17:35 se pare el solo, en vez de tener un bucle infinito que tengas que parar a mano, algo así como esto:

.
.
$hora = date("h:i");
if ($hora == "17:35") {
     // código para salir del programa
}
.
.
.

Es la forma adecuada de hacerlo.

 

[bah]

Me pareció un poco chapucero hacerlo así... ::::😀

Pregunta de examen, ¿como controlar remotamente un s-c-r-i-p-t php? razone la respuesta. (2,5 pipos)

jeje

1) archivo c:\muerete.txt
2) en el bucle infinito:

$file="c:\muerete.txt";

if (file_get_contents($file)) {
file_put_contents($file,"");
exit;
}

3) para parar: editar muerete.txt y añadir cualquier cosa 😀

 

[Benditaliquidez]

¿has probado con otro servidor web?

no he leido a fondo :o, pero yo haría un proceso shell php que lo controles manualmente, y el servidor web para mostrar el resultado. esto es independiente del servidor web.

para controlar remotamente... en windows no se, pero el proceso debería guardar un PiD en un archivo.txt, y para cancelar, hacer un kill leyendo el archivo.

Sí lo había pensado, también lo ha comentado banana, hacer un php ejecutable o lo que sea.

Lo de leer un txt, que es lo que tengo ahora entre manos, tendría que ordenarle al php que leyera el txt a intervalos regulares para comprobar el estado de esa "variable externa", el problema es que si abro el archivo txt para modificarlo entonces el php no podrá leerlo el php dará error o algo..., también es verdad que puedo poner que ignore el error o que si da error se detenga.

Voy a intentar hacerlo así.

 

[Benditaliquidez]

Por cierto, que yo ya no estoy largo porque estoy esperando a ver si saltan algún stop.