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

Sara Marugan smarugan en gsyc.es
Lun Abr 5 10:57:57 CEST 2010


Interesante. Entonces se puede utilizar conjuntamente ICE 3.3.1 e ICE 
3.4.0 en jderobot-5.0?

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
>   



More information about the Jde-developers mailing list