fork() in Windows?
I'm new to this forum and joined because of the Windows programming section. At home I run Debian, but at school we are forced to use Windows. I am currently writing a networking program which should be portable - apart from the fork()'s. So, is there any way to do a fork() in Windows? CreateProcess isn't what I need since it starts a new process instead of running a new branch of the current one.
There's really no equivalent to fork in Windows. You're choices are basically CreateProcess or CreateThread.
If you want to keep portability, you could re-work your program to be multi-threaded using a portable threading library. There are pthread implementations for Win32 for example. There's also boost::thread if you prefer a C++ library.
I agree with Codeplug - use threads. For most intents and purposes threads are better than forks - as there is less duplication of resources in the system, e.g. the amount of space that each thread uses is less than the amount of space used if you fork the entire process.
You can use a third party library, but I also think it wouldn't be difficult to "hide" the Linux vs. Windows differences in thread architecture from the rest of the code, using for example a windowsthreads.c and linuxthreads.c source file that is "choosen" based on whether you build for Windows or Linux respectively.
Obvuously using a third party thread library that is portable makes it a "no-brainer", but also adds a dependance on a third party library. It's a choice that only you can make, which of the two is "better".
Cygwin implements a fork(), by a hideous workaround: a new process is created using CreateProcess, then the parent and the child allocate a common shared memory area, and the parent transfers the entire working set to the child through the shared memory. The whole thing is absurdly slow.
OK Thanks, people.
I'll probably use a multi-platform threading library. Thanks!
no easy way to recreate fork, since it assumes both threads continue right after the fork() . CreateThread() is the prefered method in widows programming, although some of the other old fogeys still prefer beginthread. A call to beginthread really just translates to a call to createthread, plus the overhead of translating the call. its really only supported for compatibility with existing code.
I hate when people resort to using a 'threading library', since the win32 api supports all the functionality you will ever need. Why would you cripple your application by putting more code between your app and the OS?
1) It's __beginthread.
2) It's deprecated because its semantics are idiotic, not because it was superseded.
3) The new, correct function to call (in VC++) is __beginthreadex.
4) Don't use CreateThread directly in programs that use the MS CRT or the MS C++ standard library (which includes ALL C++ programs compiled with VC++).
5) Why a threading library? Well, because of portability and RAII interfaces of course. With a proper scoped_lock, you can't forget unlocking a mutex. The notion that an application is "crippled" by the intermediate layer is absurd. On the other hand, why cripple your portability by tying yourself to the Win32 API or even the MS compiler? Hah, even on the Win32 platform portability is fickle - do all compilers even support __beginthreadex? Yet not using it in VC++ leads to resource leaks.