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

[Roberto Calvo]

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


-- 
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/5b117b0f/attachment.pgp