C++博客-cyt

如何在windows service里面控制console程序退出

cyt — Tue, 08 Jan 2008 08:07:00 GMT

首先，要控制windows services，是比较容易的事情，一堆现成的例子。
SYNtService 就是一个很好的例子。
要控制一个窗口退出是十分容易的事情，PostMessage就可以解决问题。
要控制console退出，也有很多现成的方法。比较通用的方法：
1、TerminateProcess
   最原始、最暴力的强制console退出的方法。console进程毫无还手之力就over了。但我希望console在推出之前至少能处理一下“后事”。

2、signal / raise
   原来windows也有signal，不过kill换成了raise。但是相对Unix系列的signal功能就差很远了。而且有一个麻烦的地方就是raise只能对本console生效，而不能对指定的process。
   可以在signal里面指定一个call back函数，在收到SIGINT/SIGTERM之类的时候，处理一下事情，然后通知各个线程结束。
   既然不能raise其他进程，是否这个功能就不能用了呢？其实可以考虑一下CreateRemoteThread，然后在别人的进程里面raise……

3、SetConsoleCtrlHandler / GenerateConsoleCtrlEvent
    这个是console专门用来处理Ctrl-C/Ctrl-Break/以及windows关机事件等的处理方法。比signal更强大。而且说明中写了，可以对其他的进程进行处理（还可以对进程组处理）。用网上的话说就是：很女子，很弓虽！
    但是要注意，如果要对其创建的子进程进行处理的时候，创建子进程必须要使用CREATE_NEW_PROCESS_GROUP标志。另外一点，文档写的比较隐晦的就是，进程必须要有console窗口。否则，调用GenerateConsoleCtrlEvent会返回6，说ERROR_INVALID_HANDLE。
    问题来了，Service本身是没有console窗口的，Service建立的子进程就必须要自带窗口了。但是一般为了美观，Service启动的进程都不想带有窗口。那就变成了子进程没有console窗口，GenerateConsoleCtrlEvent失效了。
    在网上查了很多资料（怎么没看到很黄很暴力呢？？？），其中在 Louis K. Thomas sth@hotmail.com> 的 SendSignal 提到一种做法，就是先获得kernel32!CtrlRoutine的入口，然后通过CreateRemoteThread的方法，让远程的console来执行kernel32!CtrlRoutine。但这种方法有个问题，在获得kernel32!CtrlRoutine的时候，也是使用GenerateConsoleCtrlEvent来获得。但是Service自己本身没有console窗口，一调用GenerateConsoleCtrlEvent也是出错。
而另一篇 google讨论组文章，里面提到原来可以先AllocConsole、然后GenerateConsoleCtrlEvent、然后FreeConsole……于是解决方案就变成：
Service里面:
先AllocConsole
然后利用GenerateConsoleCtrlEvent获得kernel32!CtrlRoutine
然后FreeConsole
当需要结束进程的时候，就调用CreateRemoteThread，把kernel32!CtrlRoutine的代码注入到子process中执行
这样大家都看不到console窗口（service里面AllocConsole很快，看不到窗口出来，甚至怀疑根本就有没有窗口出来），同时又能通知子进程优雅地退出。

存在问题：如果我的机器作为服务器启动，即没有进入登录状态，不知道这样启动的Service会不会有问题呢？？暂时还没有时间测试。

cyt 2008-01-08 16:07 发表评论

中秋节快乐

cyt — Tue, 25 Sep 2007 04:16:00 GMT

摘要: 中秋节快乐！
介绍了一本书和几个C++lib 阅读全文

cyt 2007-09-25 12:16 发表评论

补充一个OCI的问题

cyt — Thu, 29 Mar 2007 16:00:00 GMT

前几天客户投诉我们提供的一个访问Oracle的程序，说运行太慢了，半天都没有处理完数据。
客户数据也就几十万条，也不是什么海量数据，究竟什么原因呢。而且奇怪的是我们提供的其它类似的程序访问同一张数据表却没有任何的问题。
经过多次反复写测试程序，尝试各种的条件，最后发现原来是其中一条update语句执行很慢，要2秒钟才更新一条。而这条update语句的where部分有两个条件，一个是整数的比较条件，一个是日期的比较条件。当然很容易就可以通过测试排除了整数条件导致慢的可能性。剩下的原因就是日期比较条件导致慢了。
说得也奇怪，日期条件是通过param的方式传入参数的，执行很慢。但测试的时候如果把日期条件展开，把日期条件变成SQL的一部分，那就执行很快了。先不论为什么这么奇怪，要知道Oracle SQL语句的日期条件不是一般的麻烦，都要经过TO_DATE/TO_CHAR糊弄来糊弄去，SQL语句跟其他的数据库不一样，程序就失去通用性了。一定是自己调用OCI的时候犯了什么糊涂错误了。
最后还是发现有一个不妥当的地方：数据库字段类型是DATE，而我用OCI绑定param的时候，用的却是SQLT_TIMESTAMP。原因是我想偷懒，希望用OraDateStruct就解决OCI的日期类型。于是我尝试用回SQLT_DAT，自己“笨笨的”把时间转换为OCI所能辨认的7个byte的数组，然后运行程序。速度太快了，一下子就执行完了。
其实不明白的是，Oracle发现类型不匹配，要不就报错；要不就把条件变为相容的数据进行查询。但是现在从现象看来，Oracle像是把所有保存的数据逐个转换成为与条件相容的类型进行判断，而不是转换条件的类型。所以每次update都变成了遍历所有的数据。难道是存在DBA可以调整的优化策略？？不明白，不明白……

cyt 2007-03-30 00:00 发表评论

OpenDBX 一个访问多数据库的C类库

cyt — Thu, 29 Mar 2007 15:31:00 GMT

http://www.linuxnetworks.de/opendbx/

OpenDBX，一个开源的、简单的、可以访问多种数据库的C类库。按作者说的，已经支持：

Firebird
Interbase
MS SQL Server
MySQL
Oracle
PostgreSQL
SQLite
SQLite3
Sybase

而且好像是使用动态载入模块方式，即dlopen打开相应驱动模块的so的方式，是有点ODBC的味道。
不过支持的数据类型以及SQL查询的功能有限。
留着以后可能会有些参考价值。

cyt 2007-03-29 23:31 发表评论

移植代码到64bits碰上的问题

cyt — Thu, 29 Mar 2007 15:15:00 GMT

一晃眼，原来又有好几个月没有上来。其间写了几个月的javascript，写了几个月的JSP，C++的东西都没有怎么碰过了。

这几天要原来项目的C++代码从32bit的平台移植到64bit的平台。由于以前编写类库的时候已经十分小心，也早有预谋，所以竟然很顺利的全部编译通过，而且-Wall下面都没有任何warning。满心欢喜之下运行了程序。谁知道马上就是一个Segment faul。沮丧之余用gdb跟踪了半天都不知道什么地方的问题。加上valgrind，也是一头雾水，竟然是说标准STL的hash_map的问题……最后在一次跟踪的时候，无意中检查一个指针的初始化值，发现不为空，原因应该就在这里。
翻查代码的上下文，原来指针是跟一个int放在同一个union当中，而union的初始化只初始化了int，而没有初始化指针。在64bit机器的gcc下，int是32bit而指针是64bit，所以就导致指针不为空的现象。所以赶紧把代码中所有union的地方都找出来检查一遍。幸好union这种东西平时不敢多用，也没发现其他的异常。程序重新编译，再运行，没有Segment fault了。

然后再运行了一批unit test。发现其中有几个不能通过，其原因其实也是比较无聊。都是自己不小心之过：
1、sha1的代码copy php的，其中一个php_uint32变量竟然自己写了unigned long，傻瓜致极
2、有个地方保存各种长度整数到文件，因为偷懒，把函数写成了模板，大概就是：
   template
      int write(typeInt n) {
         writeToFile( &n, sizeof(n));
      }
   然后一个不小心，想写个string的长度的时候就变成了： write( str.length() );
   str.length()类型是size_t，64bit，与32bit系统的不一样，当然也就出错了。
   其实平时都已经很小心，尽量使用static_cast强制转换为特定长度类型的变量再输出的了，偏偏就是漏了一两个地方。

cyt 2007-03-29 23:15 发表评论

db4o and GigaBase

cyt — Fri, 17 Nov 2006 09:11:00 GMT

    昨晚参加了db4o的RoadShow，终于见到英俊潇洒玉树临风，传说中的Matrix群主Chris
    db4o给我的印象就是不依赖关系数据库的“Hibernate”，完全就是全自动对象序列化 + 超强查询。按照官方给出的数据，其嵌入式的应用环境下性能真的是无出其右了。但按我的理解，由于没有低粒度锁，必然存在无法解决的并发冲突，或者并发读问题不大，并发更改性能应该会有影响。究竟用了什么超强技术那就不知道，或者有空找来研究一下。个人感觉db4o并不是要用来替代数据库，而是数据保存的一个辅助。十分适合用于Cache系统或者应用于嵌入式设备。db4o只提供Java和C#接口，对于目前PDA应用来说似乎要求高了点。就如Rayman所说，解决了CPU和内存问题还有一个电源问题估计PDA近期也无法解决。Christof一再强调其三段式事务保证数据文件完整；快速易用的开发模式；超大规模数据的支持……至于他们公司的开源盈利模式，小弟英文水平有限，听不懂了。
    很久以前就提到过GigaBase，似乎就是db4o的C++版本。不过C++先天不足，缺少反射机制，实现当然不能像db4o般优美了。但似乎这个选择也不错，可以告别BerkeleyDB、sqlit……从此步入OO数据保存的“天堂”……

cyt 2006-11-17 17:11 发表评论

实在惭愧

cyt — Sun, 12 Nov 2006 09:45:00 GMT

转眼原来自己已经大半年没有上来写log，同时也发现原来大半年没有去研究C++技术了。
工作的需要，这半年来一直写在javascript，一个让人又爱又恨的语言。简单灵活的语法、却又带来无穷的陷阱。换一种思考角度的开发方式，使习惯于传统语言的我开始的时候难以适应。
开发的时候经常在想如何把javascript的好处带入到C++。或许boost的any、lambda 、function 、signals可以为C++开发带入少少的javascript乐趣。

cyt 2006-11-12 17:45 发表评论

新版本的Qu

cyt — Fri, 14 Apr 2006 15:09:00 GMT

摘要: Qu语言又出了新版本，引入了很多新的、吸引人的特性。阅读全文

cyt 2006-04-14 23:09 发表评论

OCI访问Oracle的一些刁钻问题

cyt — Fri, 14 Apr 2006 14:24:00 GMT

1、CLOG/BLOG的插入
找了很多OCI的例子以及一些PHP的例子，基本上都是同一种做法：
a、OCIStmtPrepare预处理SQL语句："insert into mytable (myimg) values (empty_blob()) returning myimg into :pImg"
b、调用OCIDescriptorAlloc，用参数OCI_DTYPE_LOB，获得一个LOB的句柄
c、用OCIStmtBindByPos或者OCIStmtBindByName，把LOB句柄和参数:pImg绑定
d、OCIStmtExecute执行
e、OCILobWrite往LOB里面写数据
f、commit和释放资源等等

问题是这个SQL语句也太特别了，和其他数据库的SQL不一样。但是在java的实现中，并不需要这么奇怪的语法。
insert into mytable (myimg) values(?)
就足够了。
在我们的应用中，能够统一同一种SQL的写法当然是最好的，最好就是：
insert into mytable (myimg) values (:pImg) 那就和其他的数据处理一致了。

做了很多的尝试，终于找到解决的方法：
a、OCIStmtPrepare预处理SQL语句："insert into mytable (myimg) values (:pImg)"
b、调用OCIDescriptorAlloc，用参数OCI_DTYPE_LOB，获得一个LOB的句柄
c、通过OCILobCreateTemporary函数，为LOB句柄创建临时LOB对象
d、OCILobWriteAppend往LOB句柄写数据
e、用OCIStmtBindByPos或者OCIStmtBindByName，把LOB句柄和参数:pImg绑定
f、OCIStmtExecute执行
g、commit和释放资源等等

经过简单的封装，LOB操作简单很多了：
TDBConnection conn = TDatabase::getConnection( strConnection );
TDBStatement dbStatement(conn.getStatement());
dbStatement.prepareSQL( "insert into mytable (myimg) values (:pImg)" );
dbStatement.getParam("pImg").attachInputStream( fStream );
dbStatement.execSQL();
conn.commite();

2、空字符串
插入一个空字符串，OCIBindByPos/OCIBindByName的时候，那个字符串的数据类型，不能是SQLT_LVC，用SQLT_CHR倒是没有问题。
具体为什么，只有Oracle自己知道了。

3、指定IP连接Oracle
通过OCIServerAttach里面指定绑定的SID连接数据库。用SID连接Oracle当然有它的好处。奇怪的是JDBC能用IP和Port指定连接哪个Oracle。
找遍OCI的帮助都找不到IP连接方法。google了很久，找到解决的方法，自己生成SID：
string strSID = "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=%1)(PORT=%2)))(CONNECT_DATA=(SERVICE_NAME=%3)))";
里面的%1设为Oracle服务器的IP；%2设为Oracle服务器的Port，一般是1521；%3就是database的名字。
把这个字符串放入OCIServerAttach

cyt 2006-04-14 22:24 发表评论

Linux的系统性能监测参数获取

cyt — Thu, 02 Mar 2006 14:54:00 GMT

目前的工程需要简单的监测一下Linux系统的：CPU负载、内存消耗情况、几个指定目录的磁盘空间、磁盘I/O、swap的情况还有就是网络流量。
Linux下的性能检测工具其实都有很多。mrtg（http://people.ee.ethz.ch/~oetiker/webtools/mrtg/）就是一个很不错的选择。不过用mrtg就要装sysstat、apache、snmp、perl之类的东西。而且安装也要好几个步骤，似乎比较麻烦。本来也想直接调用sar、vmstat之类的命令，parse一下结果就算了。哪知道发现不同的版本的linux这些命令的结果也都是不一样。既然要按版本parse它们的结果，那还不如直接去系统里面获得算了。于是研究了一下sysstat（http://freshmeat.net/projects/sysstat/）和gkrellm（http://gkrellm.net ）的源代码，找到监测性能的数据所在。

1、CPU
   在文件"/proc/stat"里面就包含了CPU的信息。每一个CPU的每一tick用在什么地方都在这个文件里面记着。后面的数字含义分别是：user、nice、sys、idle、iowait。有些版本的kernel没有iowait这一项。这些数值表示从开机到现在，CPU的每tick用在了哪里。例如：
cpu0 256279030 0 11832528 1637168262
就是cpu0从开机到现在有256279030 tick用在了user消耗，11832528用在了sys消耗。所以如果想计算单位时间（例如1s）里面CPU的负载，那只需要计算1秒前后数值的差除以每一秒的tick数量就可以了。gkrellm就是这样实现的：((200 * (v2 - v1) / CPU_TICKS_PER_SECOND) + 1) /2
例如，第一次读取/proc/stat，user的值是256279030；一秒以后再读一次，值是256289030，那么CPU在这一秒的user消耗就是：((200 * (256289030 - 256279030) / CPU_TICKS_PER_SECOND) + 1) /2 = ((10000 * 200 / 1000000) + 1) / 2 = 1%了。

2、内存消耗
   文件"/proc/meminfo"里面包含的就是内存的信息，还包括了swap的信息。例如：
$ cat /proc/meminfo
        total:    used:    free: shared: buffers: cached:
Mem: 1057009664 851668992 205340672        0 67616768 367820800
Swap: 2146787328 164429824 1982357504
MemTotal:      1032236 kB
MemFree:        200528 kB
MemShared:           0 kB
……
不过从gkrellm的源代码看，有些版本没有前面那两行统计的信息，只能够根据下面的Key: Value这种各式的数据收集。

3、磁盘空间
   从gkrellm的源代码看，这个是一个很复杂的数据。磁盘分区的数据有可能分布在：/proc/mounts、/proc/diskstats、/proc/partitions等等。而且如果想要检查某几个特定的路径，还需要通过mount、df等命令的帮助。为了减少麻烦，这个数据我就直接用statfs函数直接获得了。
int statfs(const char *path, struct statfs *buf);
这个函数只需要输入需要检查的路径名称，就可以返回这个路径所在的分区的空间使用情况：
总空间：buf.f_bsize * buf.f_blocks
空余空间：buf.f_bsize * buf.f_bavail

4、磁盘I/O
   磁盘I/O的数据也同样比较复杂，有些版本看/proc/diskstats，有些版本看/proc/partitions，还有些版本至今我也不知道在那里看……不过可以看到数据的版本也像CPU那样，需要隔一段时间取值，两次取值的差就是流量。

5、网络流量
   网络流量也是五花八门，不过基本上都可以在/proc/net/dev里面获得。同样也是需要两次取值取其差作为流量值。

   以上就是数据获得源头。程序也比较好写，不外乎就是打开一些文件，逐行读出来然后用sscanf来parse一下数据就可以了。

cyt 2006-03-02 22:54 发表评论