Threads vs processes

Me acaba de alegrar ver en un email de Linus que internamente el kernel no diferencia especialmente a los procesos y los threads. Con la claridad y el estilo y la absoluta falta de "rigor" y de uso de terminos extraños. Como tiene que ser, vamos:

Please do not confuse things.

There still are no such things as "threads" vs "processes" as far as the 
kernel is concerned.

They are all the same thing, and they are all threads or processes or
whatever you want to call them. I've tried to call them "contexts of
execution" just to clarify the fact that they are _not_ threads of
processes. And they all have a unified ID space.

They just happen to share different things. We should try to avoid at all
cost to take on stupidities from legacy systems. We've got a unified
process/thread/whatever space, and that's a good thing.

Yes, when you share the signal state (and you have to share the VM and
signal handlers to do so), you end up looking like a pthreads "process".
But dammit, people should NOT think that that is all that special from a
kernel standpoint.

Este mensaje me hace pensar que despues de todo implementar rfork() probablemente sea mas un problema de "falta de ganas y de romper cosas" que por "incapacidad técnica". Al fin y al cabo no es mas que otro SMOP. En la parte de threads al menos. Los espacios de nombre por procesos, tuve la gratificante experiencia de probarlos el otro día, no hay mas que usar clone() y CLONE_NEWNS como flag. El plan de ataque fue lanzar un shell con ese flag, monte un sistema de archivos dentro de ese shell y voila - el sistema de archivos montado no existia en el resto del sistema. El problema es que requiere privilegios de superusuario. Sería un gran avance que todos pudieran usarlo. Quizas no sea mas que otro SMOP, veremos que nos prepara Al Viro para 2.6.7...

En otras noticias, parece que alguien de Microsoft ha expuesto el bonito problema que surge con la ansiada compatibilidad 32-64 bits del amd 64. Resumiendo: El kernel necesita drivers de 64 bits, por lo tanto las aplicaciones de 32 bits que funcionen en un sistema de 64 bits y que se comuniquen con los drivers (las llamadas al sistema no son el unico medio de comunicacion con el kernel hay mas mecanismos, concretamente del que habla el tio son las ioctls) no funcionarán. No todo va a ser tan simple y tan bonito a la hora de cambiarse a los 64 bits, especialmente en el mundo propietario. A veces pienso que la propuesta del amd64 da mas problemas que los que resuelve. Empezar una nueva arquitectura de escritorio de cero hubiera sido bonito, aunque habria fracasado por supuesto. Maldito dinero....