分类目录归档：Linux

Cygwin学习笔记

7条回复

为了在最短的时间内掌握Cygwin原理，我选择了MSYS的源代码来进行分析研究。

以下内容仅为阅读代码时做的笔记，非文献。

 

当一个Cygwin程序运行时，首先到达mainCRTStartup ()这个入口函数，属于newlib，在newlib的crt0.c里。

mainCRTStartup ()调用msys_crt0或者cygwin_crt0，并传递main函数的地址。

msys_crt0调用了_msys_crt0_common 和 dll_crt0__FP11per_process。

在_msys_crt0_common()里，主要给per_process结构分配空间，然后初始化结构的数据内容。

进入dll_crt0__FP11per_process()后，就不会再返回了。

接着来到_dll_crt0()，获取环境变量和进程信息，通过set_console_handler设置终端IO文件。随后调用dll_crt0_1()

在dll_crt0_1里，设置了异常处理函数，初始化resourcelocks和threadinterface，似乎给线程都分配了名字。

调用了host_dependent.init ()，不知道干了什么。

调用memory_init()，若是第一次加载dll，会创建一片共享内存区域。

调用events_init()初始化。

如果是使用fork创建的子进程，则跳到指定的地址去执行。否则，执行下面初始化：

Cygwin进程列表初始化，dtable初始化，信号处理初始化，tty初始化。

对命令行参数的路径进行转换。

 调用stdio_init()设置标准的输出输入描述符表。

至此，基本上完成了Cygwin的数据初始化。

 

最后调用dlls.init ()，调用各个premain函数。调整到user_data->main去执行。

 

至此，我大致已经清楚了Cygwin的启动流程，可以去尝试自己写一个运行库了 :D

 

经过一晚奋战，结果如下，成功执行MSYS的env.exe程序。

 

Cygwin Makes Me Crazy?

12条回复

前几天在忙着编写kernel32.dll以支持msys-1.0.dll。后来发现有点问题了。

首先，要实现的函数数量比较多，起码有100个以上。其次，我对win api不熟悉，也不感冒，对于每个api都要去msdn获取资料，相当麻烦。另外，某些api是非常难实现，例如编码转换，acl那些。

 

因此，我从昨天开始停止了继续编写kernel32了，而是转向msys-1.0.dll。msys和Cygwin是差不多的，其实就是一个简化版的Cygwin。而且使用了newlib，可移植性很好。

在编写msys的时候，又遇到问题了，我发现了里面有很多Cygwin的专用结构。对于这些结构我还不是很了解，所以基本上都没有实现。同时，我对Cygwin的工作流程也不是怎么熟悉。

 

为了让原计划继续进行，无论如何我也要把msys运行库写出来。

下一步先熟悉一下msys的源代码！！

php-cgi莫名其妙的崩溃

11条回复

homeserver通过FastCGI协议与php-cgi进程进行通信来执行php脚本文件。
一直以来都发现php-cgi进程不是很稳定，可能是我在实现协议上有不当的地方。运行一段时间后，例如一两天，phpcgi进程就会自动结束，也不留下任何相关信息。
目前，我通过写批处理文件，在进程结束后自动建立新进程来临时解决这个问题。之前在windows上是写一个批处理文件，然后copy几万行执行命令，这样就相当于无止境地执行。
在Linux上做的更简单，可能是我不知道在windows的批处理里怎么写循环。

#!/bin/bash
while true
    echo “Starting php server …”
    php-cgi -b 127.0.0.1:8080
    echo “Server exited. Restart it …t”
    sleep 10s
done

为啥要sleep 10s呢？因为php-cgi进程异常结束了，socket还在占用着8080端口，如果不睡眠一下，那么会耗尽CPU资源，知道端口能够使用。这样可能导致日志文件的体积疯狂增长，直到硬盘资源枯竭而止。。。

原来Linux和Windows下的socket还是有那么多不同的

8条回复

之前以为linux和windows下的socket都是符合posix标准的，在一个环境下能够正常使用在另外一个环境也没问题。但没想到两者还是有那么多不同。

1.最先发现的是在windows上需要调用那个WSAStartup进行初始化才能使用socket。

2.linux下关闭socket用close，而windows上用closesocket。

3.后来发现shutdown的参数名称不同，windows上用SD_BOTH，linux上是SHUT_RDWR。

4.在linux下如果不正常关闭socket会触发SIGPIPE异常，所以我使用signal( SIGPIPE, SIG_IGN );忽略之。

5.linux下可以使用read，write函数操作socket，也可以使用send，recv。windows上只能使用send，recv？（不考虑udp的sendfrom和recvfrom）

今天又发现一个很大的不同点了，造成了homeserver在短时间内生成了一个20GB的日志文件，用完了vps的硬盘空间。如果一个正在使用中的socket使用close来关闭之而不调用shutdown，则该socket还是处于连接中，只是在进程的文件描述符中移除了（right？）所以导致了使用那个socket的线程一直没有收到关闭信号，阻塞在socket的recv上无法被关闭。而在windows上调用closesocket就彻底地断开了连接了。

下面是网上提供的信息：
close—–关闭本进程的socket id，但链接还是开着的，用这个socket id的其它进程还能用这个链接，能读或写这个socket id
shutdown–则破坏了socket 链接，读的时候可能侦探到EOF结束符，写的时候可能会收到一个SIGPIPE信号，这个信号可能直到socket buffer被填充了才收到，shutdown还有一个关闭方式的参数，0 不能再读，1不能再写，2 读写都不能。

所以，以后关闭socket还是同时使用shutdown和close好。

 

补充一下（2010-06-13）：
1、在linux下，shutdown会引起在recv和send中阻塞的线程返回-1。但是在windows下，除非closesocket，否则线程仍然阻塞。

2、windows的描述符是递增的，linux的描述符是重用的。也就是说你在linux下关闭了描述符0，然后打开一个文件，这个文件就是用了描述符0。

Windows上模仿Linux下的time程序：wintime

4条回复

程序和源代码下载：upfiles/wintime.zip

Usage: wintime program
Time Recording Method:
real    The real time the program REALLY runs.
user    The time the program runs in USER mode.
sys     The time the program runs in KERNEL mode.

使用示例(亦可以把程序拖到wintime.exe运行)：

E:>wintime amend < amend/amend9.in
80

real    0m0.734
user    0m0.750
sys     0m0.000

示例2：

E:>wintime a
1
2 2
3 3 3
4 4 4 4
5 5 5 5 5

real    0m0.015
user    0m0.015
sys     0m0.000