需要好好看看ld的script file了

今天按照计划把原型推翻重新写了一遍，基本上还算顺利，但还是有些问题花了我不少的时间。

首先是fork之后，父进程需要记录子进程的pid，一遍在收到SIGCHLD信号时进行跟踪管理，没想到有时候子进程异常退出非常快，使得pid没有被记录到。虽然知道fork之后父子进程间的执行顺序是没有保证的，但是以前的应用可能不是很复杂吧。最后的方法是在子进程里面先sleep(1)保证父进程先得到执行的机会。这可能最土的方法了，不过这个只是在初始化阶段，对整个的影响不大。那位有更好的方法可以告诉我下，谢了。

reader和writer的同步采用改进后的方案后没有什么问题，但是新的问题是在执行load命令时只能关闭掉到mysql的链接才能使query语句返回，即使删掉fifo文件也不顶用，不知道这算不算是mysql connector C的一个bug呢？明天有时间发帖子问下。但是判断关闭连接的时间也是一个问题，因为此时IB的loader可能正在工作，close掉链接的话可能使得部分数据丢失或者出错。我打算做一个脚本来监控下，同时让用户自己选择关闭整个应用系统。这个需要做到loader进程的自动化管理，因为将来会有很多的reader进程，都是自动产生的。

今天还处理了下客户那里碰到的共享内存的问题，由于某个应用申请的共享内存超出了我们库里面提供的内存空间，导致应用初始化失败。这个应用很变态，我不知道为什么一定要用我们的库提供的封装而不是直接调用系统的API，负责这个应用的Leader也不能说服我，但是这位老大又不愿意更改。因为马上就到发布了，改动太大对应的测试就是很多，很难保证高质量。我想了很久才想到一种可能的解决方案，更改应用的内存布局，使得我们的库可以管理更多的内存空间，对Technique Leader讲将来如果要将server移植到linux的话再将应用更到一个更加合理的设计上去。这个方案目前看来是唯一的快捷方式，也许是唯一可行的，短时间内。所以原型一弄完就得接着这个来。

傍晚TL来问我进展，我老实告诉他我今天没有花什么时间在上面，大部分时间在调试原型，不过已经快好了，等弄得差不多了立马处理这个问题。TL的脸色显得不大好看：刚从我手下离开，就不听我的话了？呵呵！好在他还算是比较理解，答应我做完原型。半小时后总算是调试好原型，在wiki上吧上周没有总结的IB的一些问题共享了一下。立马开始调研这个问题，好在TL昨天给的网页很有用，不然我查ld和gcc的手册就得老半天了。明天得好好研究ELF和ld的script file，确认我的方案没有问题。

快过年了，事情真多啊！