[乱弹]LINUX的EXEC+FORK和WIN32的SPAWN+$(MT)

lw

最近在想如何整合二者，因为LINUX下面通常实现不少使用了FORK+EXECV的方法，这样结果就是在WIN32下面不容易找到简单的转换方式：
fork调用返回了一个PID给父进程，惯用法一般是父进程作其他的事情，并且在需要的时候等待子进程消息或者结束信号，子进程在产生之后的位置进行调用，并且复制了之前父进程的数据，之后数据而必分离，使用COW的方式——

而WIN32下通常在一个进程中EXECV的话会等于关闭当前进程，而类似于SPAWN或者SHELLEXECUTE的方式又失去了联络子进程的方式，另外等待操作需要涉及内部的实现问题

感觉这里一直没有一个比较理想的解决方案呢——
觉得无聊就当偶吐槽好了XD

rednaxela

CreateProcess()并不会关闭任何东西,如果没有被指定的话.同样会返回进程句柄,同样可以通信...

Miliardo

最理想的方案应该是Cygwin……？（被Pia飞）

嘛，问题是Unix很长一段时间是利用OS的进程优化优势，把进程代替线程用的。
反过来说，Unix类系统往往派生进程很快，在负担不大的情况下，进程和线程之间的差别不是那么明显。（低负荷状态下Linux的进程一度可以和Windows的线程比速度）

而Windows则是要求『彻底线程化』，大概是因为这样，所以Windows的进程派生是慢到家的。
只要比较一下一个GNU autoconf生成的configure脚本，在Windows和Unix上的执行速度的差异，大家马上就都会明白。

另，如果不做特殊处理，Windows似乎是没法实现fork()的。
但如果fork+exec，功能上确实可以用CreateProcess()代替。

rednaxela

嘛,可以去参考下一些开源项目的实现.不少在从linux port到windows时都是用CreateProcess()来包装原本的fork()+exec().只不过这CreateProcess的用法多得不行,麻烦...
拿Win32进程当线程用自然是不现实的,不过需要workaround的时候这也是一个option就是了

john_he

Windows下的fork()……恶趣味啊……

真的要实现win32下的fork，而且是进程实现的话，估计就要注入代码了，这样可能需要一个空的执行文件做模块，因为Windows不能凭空创造进程，而且注入操作可能会被一些讨厌的杀毒软件或防火墙拦截。如果是线程实现的话应该就简单点，分配一块内存空间，修改属性为可执行，获取子线程要执行的代码块复制到分配的内存空间，补上函数调用所需的框架，CreateThread执行即可，不过这样就有线程同步问题要处理……

exec要实现，估计也是注入了……其实不在意进程不同的话CreateProcess后exit不是更简单？

Linux内核不太了解，不过估计实现fork和exec也是要注入的，Windows的API相对比较封闭而已……

以上个人观点……

lw

可以举例子么？
基本上LINUX下面常用的方式是：
if ( (pid = fork()) == 0 ) {
    // 子进程执行的代码，数据从父进程中完全获得，然后可以另外修改
  ...
    exit(0);
} else {
    // 父进程
  ... other
}
主要的麻烦就是很难把WINDOWS定位执行一个代码片断——
另外偶想知道WINDOWS是怎样类似于LINUX的进程之间通信的——确切说偶不太懂SIGNAL WAIT——看了也糊糊涂涂。。。
有没有什么讲的稍微明白一些，主要是交互部分，SIGNAL的设置之后子进程什么时候＋如何调用

嗯，自己也下去重新看一遍把

john_he

Windows要协作主要还是用线程，数据共享一般用CriticalSection等互锁机制。
如果真的要用到进程，可以用管道和内存映射文件通讯。

等待进线程用WaitForSingleObject、WaitForMultipleObject……

coolpay64

論效能某比較相信Cygwin
因為某認為Thread是比較混亂。。
Wait For等等的。。某還沒有學。。慚愧

lw

不是不是＝　＝！
偶想表达的通讯是如何基于现有的LINUX的用法——

主要是不清楚SIGNAL的用法，因为WINDOWS下面没有wait函数————但是有signal而且和linux一样，估计不太会是，哦…………可能是WaitFor以后的返回值不同！！

某先下去试验了……