[Jde-dev] Metodos asíncronos, no-bloqueantes y threads en ICE

[Roberto Calvo]

El lun, 05-04-2010 a las 10:57 +0200, Sara Marugan escribió:
> Interesante. Entonces se puede utilizar conjuntamente ICE 3.3.1 e ICE 
> 3.4.0 en jderobot-5.0?

mmm si el API es compatible y tienes las dos versiones instaladas
supongo que si.

Pero lo que he comentado sobre las versiones, es que para el mecanismo
de AMI hay que tener cuidado porque cambia el api de la versión 3.3.1 a
la 3.4.0. No voy a utilizar las 2, de hecho sólo utilizo la 3.3.1 de
momento ya que es la versión de referencia para JDEROBOT.

un saludo!

> 
> un saludo
> 
> 
> Roberto Calvo wrote:
> > Buenas!
> >
> > Os comento un problema que he tenido durante todo el día de hoy y que he
> > encontrado varias soluciones en ICE 3.3.1 e ICE 3.4.0 y quería dejarlo
> > documentado por si alguna vez necesitáis utilizar llamadas
> > no-bloqueantes en vuestra interfaz.
> >
> > El caso, es que hay una llamada ICE de mi interface que es
> > startRecording, que simplemente tiene que empezar a grabar vídeo en
> > disco. La llamada no quiero que sea bloqueante, es decir alguien la
> > llama, y se le devuelve que ha empezado bien la grabación y listo. Y de
> > alguna manera cuando termine, que notifique a quien le llamo, pero que
> > no sea bloqueante. 
> >
> > El caso es que si dentro de la implementación de la llamada que ofrece
> > el interface, utilizo ICE::Thread, o phtreads, o execv, o system, o
> > forks para realizar la grabación ... no retorna nunca esa llamada del
> > interfaz hasta que termina el thread. Es decir, da igual los threads que
> > crees nuevos, hasta que no terminen no retorna la llamada al interfaz.
> >
> > Tampoco vale la opción, que he probado, y que usó David para el
> > camera-server (AMD), que permite que las llamadas se encolen, y eso
> > significa que se puedan atender nuevas peticiones aunque no se haya
> > procesado las anteriores (pero hasta que no termine el proceso de la
> > imagen no se devuelve el retorno de la llamada). 
> >
> > Quizás en el siguiente dibujo-diagrama queda más claro el problema que
> > tengo:
> >
> > (1) [Lo que pasa con una llamada a la interfaz]
> >
> >   RecordingManager				Recorder
> >
> >       |----------- (startRecording) ------------->|
> >       |						  | 
> >           				    (thread-ffmpeg)
> > 						  |
> > 					    	  |
> >       |<------------      OK    ------------------|
> >
> >
> > (2) [Lo que quiero que pase]
> >
> >   RecordingManager				Recorder
> >
> >       |----------- (startRecording) ------------->|
> >       |						  | (thread-ffmpeg)
> >       |<------------  	OK    --------------------|      |
> > 						         |
> > 						         |
> >
> >
> > He estado mirando por la doc de ICE y he visto sobre la definición de
> > métodos como AMD (Asynchronous Method Dispatch)[1] (lo que usa David en
> > cameraserver), pero eso es para poder atender varías a la vez, pero no
> > deja de ser bloqueante la llamada. 
> >
> > Según veo en el manual[2], la versión 3.4.0 de Ice ha añadido una nueva
> > api para solucionar este problema ("AMI") Asynchronous Method
> > Invocation. Nosotros trabajamos con la versión 3.3.1 así que en [3]
> > sobre la página 1024 empieza a contar todo sobre AMI y como
> > implementarlo. Ha cambiado la forma de usarse de a 3.3.1 a la 3.4.0 así
> > que hay que tenerlo en cuenta dependiendo de donde ejecutemos el
> > software.
> >
> > Gracias a esta solución de programación asíncrona (AMI) que permite ICE,
> > podemos llegar a implementar el escenario (2) que os he comentado
> > arriba. Aún no he subido el código al subversion porque necesito
> > retocarlo para que os compile bien, pero funciona :-). En cuento lo suba
> > os lo comento para que lo echéis un vistazo por si os interesa.
> >
> > un saludete!
> >
> >
> > [1] http://www.zeroc.com/doc/Ice-3.4.0/manual/Cpps.9.8.html
> > [2] http://www.zeroc.com/doc/Ice-3.4.0/manual/Cpp.7.15.html
> >
> > [3] http://www.zeroc.com/download/Ice/3.3/Ice-3.3.1.pdf
> >
> >
> >   
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Jde-developers mailing list
> > Jde-developers en gsyc.es
> > http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
> >   
> 

-- 
Roberto Calvo Palomino          | Libre Software Engineering Lab (GSyC)
Tel: (+34) 91 488 85 23         | Universidad Rey Juan Carlos
rocapal en libresoft.es            | Edif. Departamental II - Despacho 116
http://libresoft.es/            | c/Tulipán s/n 28933 Móstoles (Madrid)

GPG-KEY: http://gsyc.es/~rocapal/rocapal.gpg
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 198 bytes
Descripción: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
 digitalmente
Url        : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20100405/5a9f80c4/attachment-0001.pgp