Un vistazo al código de chrome

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