工作中的一点小总结

  1 中午同事过来问mysql里面插入二进制数据的问题。以前弄过，可惜都忘了，只好重新查了下邮件。这里还是记下来当时的调查：1) 利用api里面的prepare函数，这种方法我觉得比较适合于再程序里面批量插入数据；2) 将二进制数据转换成16进制，加上0x表示，这个因为要单个处理全部的二进制数据，但是不需要设置prepare函数的诸多参数，比较适合单个的插入。我记得当时我用的是prepare函数，设置bind的参数也是花了一定时间看mysql的reference doc和测试的。 3) convert和cast函数对我们的场景而言不合适，因为我们接收到的就是二进制数据，插入到表的列定义也是二进制的。

  2 offload server上在多个服务进程存在的时候性能不是单个进程时的线性关系，差了很多。当时分析是多进程间争用FIFO的原因。今天想到一种方法可不可以这样：利用global data area来取代FIFO，在global data area中创建一个队列，里面保存有一系列node，node里面保存有一些内存空间。工作流程是这样：首先取得信号量，从队列中取出一个node，根据自己收到的数据长度，设置node，然后释放信号量，最后将数据填入到node指向的内存中。优点是尽量减少了信号量的持有时间。但是一个大缺点是读取的时候怎么办？reader得到了一个合适的node，但是此时可能node里面并没有放入全部的数据，难道还需要同步？因为有多个写者，数目还不确定，在list中设置缓冲也不明智啊。

3 我有一个类，封装了信号量的操作。构造之后，init函数需要接受一个key值作为信号量的key，init里面首先用不带IPC_CREATE去取信号量，如果发现没有则用IPC_CREATE去创建一个信号量，如果没有失败，则根据init的参数去初始化信号量。多个进程都会用同一个key值去创建信号量。外部调用init的，会判断errno是否为零。但是偶然情况下会有一个进程返回失败（init）。根据打印的错误消息，在IPC_CREATE创建这个信号量的调用并没有返回失败，那怎么会init返回失败呢？没大想明白。今天太忙，明天有时间查查原因。其实应该将创建和使用分开，在父进程里面创建好，子进程只要去根据key取信号量是最安全的。