Una de los aspectos que más me ha interesado de chrome es su arquitectura, aquello de
ejecutar un proceso por pestaña para dejar que el sistema operativo haga unos de los trabajos para los que está diseñado: aislar procesos independientes y gestionar la memoria. Entonces he decidido a echarle un vistazo al código, que para eso está ahí ;)
Lo primero que hay que decir es que el
IPC se hace mediante
pipes con nombre, como parece que debería ser, aunque sea una de esas características de los SO en decadencia, o por ser más preciso, menos de moda.
El documento que describe el IPC en chromium es escueto así que he hecho una inmersión en el código, aunque superficial, sobre todo para encontrar detalles de implementación. Los mensajes se gestionan con una clase
ChannelProxy (definida en
src/chrome/common/ipc_channel_proxy.h) Las pipes se gestionan con la clase
Channel (mismo directorio,
icp_channel.h) Curiosamente está implementada llamando directamente a la API de
win32, ella misma hace de capa de abstracción y de interfaz a implementar.
Otro aspecto que me llamaba mi curiosidad es la serialización de los mensajes y lo hacen especializando
Read,
Write y
Log de
ParamTraits (en
src/chrome/common/ipc_message_utils.h) a la estructura o tipo de dato en concreto. La serialización los tipos de datos primitivos están en
Pickle (
src/base/pickle.cc), que es base de
Message (
src/chrome/common/ipc_message.cc)
Como uno de mis intereses es la
multiplataforma he buscado como solucionaban la gestión de threads y procesos. Acerca de los threads se han creado un interfaz sencillo en
src/base/platform_thread.h con dos implementaciones,
platform_thread_win.cc y
platform_thread_posix.cc. Cabe destacar el siguiente comentario de este último fichero:
The POSIX standard does not provide for naming threads, and neither Linux
nor Mac OS X (our two POSIX targets) provide any non-portable way of doing
it either. (Some BSDs provide pthread_set_name_np but that isn't much of a
consolation prize.)
Que creo que dice algo de su política y no se si gustará mucho a los BSDros... El buceo por la gestión de procesos ha sido un poco decepcionante porque sólo existe un
process_util::LaunchApp que básicamente llama a un
CreateProcess de nuevo de la API de
win32. Seguramente han ido pensado previamente en los interfaces y solo están a falta de la implementación en distintas plataformas, pero da una sensación de
trabajo a medias, quizás reflejo de un proyecto real (en contraposición de una prueba de concepto) saliendo de su fase temprana. Cabe preguntarse cuanto les costará implementar y testear esas funcionalidades... Ah, calla, que somos millones los
betatesters.
(Actualización) Un tímido buceo en
src/net/base me dice que el código de red es muy
windowscéntrico, con muchas inclusiones de
winsock2.h, incluso en cabeceras :/ aún les queda trabajillo por delante. Los interfaces de las clases parecen bien definidos y eso les ahorrará trabajo, pero es bien sabido que un interfaz no es válido y está maduro hasta que no funciona en todas la plataformas a las que se dirige...
Uhmmm, acabo de ver un enlace de donde se baja las
fuentes que se suponen del desarrollo en linux. Seguiremos informando, pero ya sólo esta distinción de obtención de fuentes no da buena espina...
(Actualización2)Ya lo he bajado pero es básicamente el mismo código. Me debo estar perdiendo algo, porque sino está muy verde...
(Actualización3) Leo en
kriptópolis que Chrome usa
CSP en lugar de PKCS :O No hay rastro de ningún PKCS (11 por ejemplo, el que usa El DNIe) ni de NSS (la librería criptográfica de Netscape que usa firefox) Me temo que la
portabilidad no se la han tomado en serio o quieren que se la hagan otros... Alucino.
(fin actualizaciones).
Desde el punto de vista gráfico he visto que tiene muchas de dependencias de la
WTL, lo que dice también poco de la portabilidad en primera instancia. Ya veremos a ver como solucionan ese temilla, aparentemente con lo que figura en
src/base/gfx. No obstante hay pocos restos de WTL en los .h, así que quizás ya van bastante adelantados... Misma sensación de
a medias.
Seguro que habría mucho más que decir, sobre todo del diseño e implementación de JavaScript,
V8 pero creo que se escribirá de eso suficiente (ya se ha escrito mucho de su eficiencia, veremos cuanto hay de
hype) y de temas relacionados como
la ejecución de ruby sobre V8... Ains que bien se lo hace google ;)
La misma entrada y más comentarios en Un vistazo al código de chrome en barrapunto
