尽管现在已经放假，没有太多的心思放在开发上，但是Goj项目开发最近一直在缓慢的保持着。最近主要是处理judger与ojsite通信的问题，其过程中并没有遇到什么特殊的问题，TCP以及HTTP协议什么的都不成问题。但是在今天调试提交编译任务时却发现了一个有趣的事情，那就是gcc在特定情况下变成了deamon进程。

事情经过是这样的，但凡judger都必须经历#include "/dev/random"的考验，至於这是什么、为什么我也懒得解释，下面引用知乎上的一段话，感兴趣的自己看全文：

小心编译期间的一些“高级功能”，比如 C 的 include 其实是有很多巧妙的用法，试试看在 Linux 下 #include "/dev/random" 或者 #include "/dev/tty" 之类的（这两个东西会把网络上不少二流 OJ 直接卡死……）。

而我的judger是这么解决这个问题的，创建一个线程监控编译子进程，超过一定时间kill。这样原本是没有太大的问题的，而且我也相信这也是一种正确的解决方案，但问题是我并不是直接用judger去调用gcc的，而是将gcc包装到了shell脚本，然后调用sh去执行脚本，这样做也是初期考虑到灵活性而决定的。于是judger的子进程是bash，而gcc是bash的子进程，编译任务阻塞后kill掉的是sh，于是gcc变为了孤儿进程，被init进程收养。

这倒不是什么难题，只要将进程改为能够kill掉gcc及其子进程便可解决，但是若是忽略这个问题将会是一个灾难，每一次#include "/dev/random"都将会让服务器产生deamon化的gcc进程，时间一久再多的内存都将会被gcc吃掉。