🚀 go-pugleaf

Mario Teijeiro Otero escribi�:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ignacio Pach�s Giner <ipaches@dsic.upv.es> writes:
>
> >     Hola y
> >     Al grano...:
> >
> >     Tengo un sistema con RT-Linux version 1.1 (n�cleo  2.0.36). En linux
> >
> > tengo un proceso puesto a la m�xima prioridad que se comunica con
> > RT-Linux.
> > Este programa env�a tramas por sockets a un servidor remoto de la forma
> > m�s normal.
> >     El proceso linux se queda bloqueado esperando una lectura por las
> > fifo cada
> > ciclo principal de ejecuci�n. Dentro de estos ciclos realiza siempre
> > alguna escritura
> > en el socket. Sin embargo, no consigo ver en el servidor remoto las
> > tramas hasta
> > que finalizo con el programa y lo cierro junto con las tareas de
> > RT-linux. Env�a
> > todas las tramas al final.
> >
> >     �C�mo consigo bloquear al programa cada vez hasta que toda la trama
> > haya sido
> > enviada?
> >
> >     �Necesitar� aumentar el protocolo e incluir una respuesta a la que
> > deba
> > esperarme para conseguir la sincronizaci�n?
> >
> > Gracias
> >
>
> Me parece raro lo que te pasa.
>
> Me choca que el proceso RTLinux escriba datos para arriba sin que el
> de arriba se los pida. Recuerda que si la fifo se llena, todo lo que
> se escriba en ella se pierde.
> Tambi�n me choca que el proceso Linux lea en una /dev/rtf0 de forma
> bloqueante, y que luego tb en se bloquee en las llamadas a sockets.
> Si se bloquea en la llamadas de sockets, el proceso RTLinux puede
> sobrecargar la rtfifo y perder datos enviados.
>
> Yo actualmente hago:
> le conecto una funci�n de callback en RTLinux para que sea llamada cuando
> hay algo que leer de una fifo. As�, cuando el proceso linux quiere leer
> algo de RTLinux le env�a un comando por una fifo LIN2RT, entonces se
> ejecuta la funci�n que se registr� antes, y �sta se encarga de coger los
> datos del proceso RTLinux y se las env�a al linux mediante otra fifo RT2LIN.
>
> Con esto ganamos en que el proceso RTLinux no pierde nunca tiempo en enviar
> datos para arriba, y el tiempo de espera de la Tarea Linux es minimo.
> - --
> vi vs emacs: Es como el papel del water: o lo pones con el papel colgando por
> delante o por detr�s, pero siempre lo pondr�s por el mismo lado.
>                                 (Xavier Gonz�lez Onrubia)
>
> ====================================================================
> Mario Teijeiro Otero           mailto:asimovi at teleline dot es
> Powered by Hispafuentes 6.1    clave: correo con Asunto: "[PGPKEY]"
> Usr. Reg. 122438               o en http://www.terra.es/personal2/asimovi
> ====================================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.1 (GNU/Linux)
> Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
>
> iD8DBQE5LwQxMKsc+XeZcdwRAuKpAJkBRqHZs1/p74CT9vnpMoY1gTcoBwCfXWRY
> qhgf0eCOFitt3S/+p5tU7gw=
> =is/n
> -----END PGP SIGNATURE-----

El proceso linux se bloquea en la lectura de la fifo de forma intencionada. RTl
controla mediante la escritura
en la fifo cuando se ejecuta este proceso en linux y s�lo se escribe cuando interesa.
Eso funciona bien, sin
embargo, durante la ejecuci�n del proceso linux, no salen tramas tcp a la red por mucho
que la escritura en
el socket no d� ning�n problema.
    Al final de la ejecuci�n, si de la fifo el proceso linux lee 'fin' entonces el
proceso cierra todo y sale.
Entonces es cuando se reciben todas las tramas tcp-ip, pero no durante.

    Los callbacks tambi�n los utilizar� para otro menester.