martes, agosto 31, 2004
viernes, agosto 27, 2004
lunes, agosto 23, 2004
Estoy al final de la jornada de hoy, y para acabar esta retomando la lectura del libro de Andrei Alexandrescu, que lo tenia abandonado desde hacía mucho, pero que mucho tiempo.
Esto me ha recordado el echar un vistazo a su web y he visto 2 cosillas:
Esto me ha recordado el echar un vistazo a su web y he visto 2 cosillas:
- Que ha publicado junto con Scott Meyers, en DDJ un articulo divido en 2 partes (Julio y Agosto del 2004) titulado 'C++ and the Perils of Double-Checking Locking'). Siendo usuario a DDJ se pueden ver los articulos.
- La segunda es que se tiene un proyecto entre manos (a largo plazo, ya que ahora lo que le lleva mas tiempo es su investigación sobre como 'optimizar compiladores para lenguajes avanzados', con Craig Chambers), la libreria YASLI, 'Yet another Standard Library Implementation'. De momento sólo tiene 2 clases: flex_string y vector.
miércoles, agosto 18, 2004
Lo que ha continuación publico son dos posts que publique el 17/05/2004 pero en otro weblog, por error:
Si es que ultimamente no estoy haciendo nada realmente interesante.
El proyecto es un monstruo bastante inmanejable. Esto de proyectos tan grandes con tanta gente involucrada y con fechas ajustadas es una bomba de relojeria. Veremos cuando estalla esta...
La gente que al final tenga que mantener esto va a tener trabajo para largo.
Bueno lo ultimo interesante realizado es meter unas temporizaciones para evitar que el GUI cliente CORBA se quede esperando indefinidamente una respuesta que nunca va a llegar. Eso ocurre porque en el GUI tienen puesto el 'max block time' con un valor muy algo.
El problema (que fue una muy mala idea de diseño) fue que entre el servidor del GUI y los procesos que realizan realmente las operaciones, la comunicacion es por colas y si uno de estos procesos se cae pues no nos dabamos cuenta.
Habia una solución que consistia en detectar el envio de mensajes duplicados, pero no era suficiente.
La idea era temporizar cada envio de mensaje, teniendo dos opciones:
Me decanté por la segunda opción, ya que sólo se tiene un thread, hay una menor gestión de objetos de pequeño tamaño (que hay que crear en el heap por temas de la libreria de threads que usamos), con lo cual se van a consumir menos recursos (y menejar menos threads, claro).
Además la librería de threads no permite la cancelacion de los mismos porque se hace a través de señales. Es por ello que ese control se ha tenido que llevar a la clase temporizador creada y se consume mas recursos que si se pudiese haber hecho con los mecanismos proporcinados por la libreria.
Cuanto mejor nos hubiera ido si hubieramos hecho todas las comunicaciones con CORBA...
Todo este tema de detección de servidores la hubieramos tenido automáticamente. Además no me tendria que haber currado el mecanismo para simular llamadas sincronas a través de colas. Vamos, que hubiesemos ahorrado trabajo.
¡Ah! me acabo de acordar...
Hace poco debido seguramente a alguna compilación incorrecta se producian cores (conflictos entre la libreria de acceso a la BD y el ORB). La solución fue poner el ORB como monothread. Como el ORB no lo soporta basta con poner 1 solo thread en el pool. ¿Simple verdad?
Por cierto me volvió a salir el tema de saber desde el servidor información sobre el cliente que está conectado. Me lo preguntó JJ.
La respuesta..., pues chungo no se puede así a priori.
Básicamente hay 2 posibilidades. O bien en las invocaciones se realiza o bien el ORB proporciona mecanismos para pasar informacion de cliente a servidor de manera trasparente.
Pero TIDORB que yo sepa no permite nada de eso. Con TAO se pueden usar contextos e interceptores.
Tengo un post al respecto (el del 16 de abril).
Del libro de Vinosky:
"Because IDL contexts are unsafe, we recommend that you avoid using them. It is also
possible that contexts may be removed from CORBA, so the future of this (mis)feature is
uncertain anyway."
Quizas haya ORBs que a través del objeto Current, se pueda sacar algo, pero el estandar ya no dice nada de ello.
Bueno de todas formas el estandar que estoy manejando es el 2.2 que es el que implementa en su totalidad el ORB que estoy usando.
Y bueno para ir acabando unos cuandos apuntes:
En el estandar 2.2 hablan de los objetos Context en el capitulo dedicado al Dynamic Invocation Interface, el 5. A partir del punto 5.5
Según leo en el punto 5.6.1 con la operacion get_default_context del interface ORB se obtiene el default context del proceso.
De un correo a JJ: "No he visto (de momento) nada sobre el default context de una operacion, pero debiera ser posible obtener esto.
Tras un poco mas de investigacion, veo que quizas con el pseudoobject ServerRequest se pueda acceder al contexto de una operacion. Grrrr, esto se empieza a poner interesante.
Habría que mirar en mas detalle el Dynamic Skeleton Interface, capitulo 6.
Y el mapping del ServerRequest a C++, el punto 20.36.
Según este ultimo apartado el ServerRequest es una clase en el namespece CORBA y entre sus metodos está el ctx() que nos devolveria el contexto.
La duda existencial que tengo ahora es si se puede acceder a esta informacion desde un servant normal o tiene que ser un servant DSI , los cuales heredan de DynamicImplementation. Literalmente:
" Y a continuacion lo que era el segundo post...
Inferno sigue vivo
Vaya sorpresa me he llevado hoy al leer esta noticia en slashdot. Resulta que el sistema operativo Inferno sigue vivito y coleando, tanto que te lo puedes bajar de aqui.
La primera vez que supe de él fue por unos articulos publicados ya hace muchisimo tiempo en la extinguida revista RPP, pero hasta la fecha de hoy practicamente no se ha sabido nada de él.
Otra detalle interesante de la noticia, es que comentan que es una 'evolución' de Plan 9.
Uf! que mierda
Si es que ultimamente no estoy haciendo nada realmente interesante.
El proyecto es un monstruo bastante inmanejable. Esto de proyectos tan grandes con tanta gente involucrada y con fechas ajustadas es una bomba de relojeria. Veremos cuando estalla esta...
La gente que al final tenga que mantener esto va a tener trabajo para largo.
Bueno lo ultimo interesante realizado es meter unas temporizaciones para evitar que el GUI cliente CORBA se quede esperando indefinidamente una respuesta que nunca va a llegar. Eso ocurre porque en el GUI tienen puesto el 'max block time' con un valor muy algo.
El problema (que fue una muy mala idea de diseño) fue que entre el servidor del GUI y los procesos que realizan realmente las operaciones, la comunicacion es por colas y si uno de estos procesos se cae pues no nos dabamos cuenta.
Habia una solución que consistia en detectar el envio de mensajes duplicados, pero no era suficiente.
La idea era temporizar cada envio de mensaje, teniendo dos opciones:
- Lanzar un temporizador por mensaje. Si cuando caduque el temporizador no se ha recibido respuesta habrá que eliminar el mensaje y notificar el cliente.
- Tener un temporizador permanente que cada cierto tiempo compruebe si alguno de los tiempos para los mensajes enviados ha caducado.
Me decanté por la segunda opción, ya que sólo se tiene un thread, hay una menor gestión de objetos de pequeño tamaño (que hay que crear en el heap por temas de la libreria de threads que usamos), con lo cual se van a consumir menos recursos (y menejar menos threads, claro).
Además la librería de threads no permite la cancelacion de los mismos porque se hace a través de señales. Es por ello que ese control se ha tenido que llevar a la clase temporizador creada y se consume mas recursos que si se pudiese haber hecho con los mecanismos proporcinados por la libreria.
Cuanto mejor nos hubiera ido si hubieramos hecho todas las comunicaciones con CORBA...
Todo este tema de detección de servidores la hubieramos tenido automáticamente. Además no me tendria que haber currado el mecanismo para simular llamadas sincronas a través de colas. Vamos, que hubiesemos ahorrado trabajo.
Solventar problema en modo MT
¡Ah! me acabo de acordar...
Hace poco debido seguramente a alguna compilación incorrecta se producian cores (conflictos entre la libreria de acceso a la BD y el ORB). La solución fue poner el ORB como monothread. Como el ORB no lo soporta basta con poner 1 solo thread en el pool. ¿Simple verdad?
Sobre paso de informacion de cliente a servidor en CORBA
Por cierto me volvió a salir el tema de saber desde el servidor información sobre el cliente que está conectado. Me lo preguntó JJ.
La respuesta..., pues chungo no se puede así a priori.
Básicamente hay 2 posibilidades. O bien en las invocaciones se realiza o bien el ORB proporciona mecanismos para pasar informacion de cliente a servidor de manera trasparente.
Pero TIDORB que yo sepa no permite nada de eso. Con TAO se pueden usar contextos e interceptores.
Tengo un post al respecto (el del 16 de abril).
Del libro de Vinosky:
"Because IDL contexts are unsafe, we recommend that you avoid using them. It is also
possible that contexts may be removed from CORBA, so the future of this (mis)feature is
uncertain anyway."
Quizas haya ORBs que a través del objeto Current, se pueda sacar algo, pero el estandar ya no dice nada de ello.
Bueno de todas formas el estandar que estoy manejando es el 2.2 que es el que implementa en su totalidad el ORB que estoy usando.
Y bueno para ir acabando unos cuandos apuntes:
Tras un poco mas de investigacion, veo que quizas con el pseudoobject ServerRequest se pueda acceder al contexto de una operacion. Grrrr, esto se empieza a poner interesante.
Habría que mirar en mas detalle el Dynamic Skeleton Interface, capitulo 6.
Y el mapping del ServerRequest a C++, el punto 20.36.
Según este ultimo apartado el ServerRequest es una clase en el namespece CORBA y entre sus metodos está el ctx() que nos devolveria el contexto.
La duda existencial que tengo ahora es si se puede acceder a esta informacion desde un servant normal o tiene que ser un servant DSI , los cuales heredan de DynamicImplementation. Literalmente:
20.36.3 Mapping of PortableServer Dynamic Implementation Routine
In C++, DSI servants inherit from the standard DynamicImplementation class.
This class inherits from the ServantBase class and is also defined in the
PortableServer namespace. The Dynamic Skeleton Interface (DSI) is
implemented through servants that are members of classes that inherit from dynamic
skeleton classes.
"
Inferno sigue vivo
Vaya sorpresa me he llevado hoy al leer esta noticia en slashdot. Resulta que el sistema operativo Inferno sigue vivito y coleando, tanto que te lo puedes bajar de aqui.
La primera vez que supe de él fue por unos articulos publicados ya hace muchisimo tiempo en la extinguida revista RPP, pero hasta la fecha de hoy practicamente no se ha sabido nada de él.
Otra detalle interesante de la noticia, es que comentan que es una 'evolución' de Plan 9.
viernes, agosto 13, 2004
jueves, agosto 12, 2004
Necesito pasar de un fichero en formato RM a MP3. Lo ideal sería pillar algo freeware, pero todavia no he pillado nada.
Creo que fue en tucows donde me salió una aplicación que no he podido mirar por un core del firefox.
Anyway, hasta ahora he visto Freecorder, que por lo visto graba lo que suena por el altavoz, pero a mi no me ha funcionado. Ah! y en baja calidad, para más, hay que registrarse, por lo que de freeware, ni de coña.
El otro, que todavia no he podido mirar es el River Past Audio Converter 5.0.4. Ahora mismo no tengo el link, por el susodicho core, pero google seguro lo saca.
Este segundo por lo visto necesita: Direct Show 8.0 y Windows Media Format 9 runtime.
Seguiremos informando.
Creo que fue en tucows donde me salió una aplicación que no he podido mirar por un core del firefox.
Anyway, hasta ahora he visto Freecorder, que por lo visto graba lo que suena por el altavoz, pero a mi no me ha funcionado. Ah! y en baja calidad, para más, hay que registrarse, por lo que de freeware, ni de coña.
El otro, que todavia no he podido mirar es el River Past Audio Converter 5.0.4. Ahora mismo no tengo el link, por el susodicho core, pero google seguro lo saca.
Este segundo por lo visto necesita: Direct Show 8.0 y Windows Media Format 9 runtime.
Seguiremos informando.
miércoles, agosto 11, 2004
martes, agosto 10, 2004
Como ando un poco apatico en el curro he estado leyendo unos articulos que tenía impresos en el curro sobre CCM (CORBA Componente Model), las partes primera y segunda de una serie de articulos. El primero de ellos es de Febrero del 2004 y se pueden conseguir en la web de C/C++ Users Journal (www.cuj.com).
He mirado un poquillo que habia por la web y me he encontrado con la siguiente página de un tio de aqui, que por lo visto esta metido en estos fregados, http://ditec.um.es/~dsevilla/ccm/index.shtml.
Aqui, va la release info de CORBA 3, que incluye CCM.
Un articulo de Doug y mas gente comparando implementaciones.
Y la página de CIAO, 'the Component Integrated ACE ORB'.
Ya para acabar, según el primero de los dos articulos que he leido, existen las siguientes implementaciones de CCM (aparte de CIAO):
He mirado un poquillo que habia por la web y me he encontrado con la siguiente página de un tio de aqui, que por lo visto esta metido en estos fregados, http://ditec.um.es/~dsevilla/ccm/index.shtml.
Aqui, va la release info de CORBA 3, que incluye CCM.
Un articulo de Doug y mas gente comparando implementaciones.
Y la página de CIAO, 'the Component Integrated ACE ORB'.
Ya para acabar, según el primero de los dos articulos que he leido, existen las siguientes implementaciones de CCM (aparte de CIAO):
- OpenCCM
- K2 Containers
- MicoCCM
- Quedo
Suscribirse a:
Comentarios (Atom)