From: vischne AT ibm DOT net Subject: On the subtleties of using _beginthread to implement fork 12 Nov 1997 18:34:46 -0800 Message-ID: <199711130033.AAA13154.cygnus.gnu-win32@out1.ibm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: gnu-win32 AT cygnus DOT com Some beginning programmer wrote to me that _beginthread was not suitable for a fork() implementation because it supposedly uses the `same data segment' as its parent process. Without discussing the subtleties of calling GlobalAlloc(), or even its disguised sibling, malloc(), I present a description of _beginthread(): #include unsigned long _beginthread(_USERENTRY (*start_address)(void *), unsigned stack_size, void *arglist) Description Starts execution of a new thread. Note: The start_address must be declared to be _USERENTRY. The _beginthread function creates and starts a new thread. The thread starts execution at start_address. The size of its stack in bytes is stack_size; the stack is allocated by the operating system after the stack size is rounded up to the next multiple of 4096. The thread is passed arglist as its only parameter; it can be NULL, but must be present. The thread terminates by simply returning, or by calling _endthread. Either this function or _beginthreadNT must be used instead of the operating system thread-creation API function because _beginthread and _beginthreadNT perform initialization required for correct operation of the run-time library functions. This function is available only in the multithread libraries. Return Value _beginthread returns the handle of the new thread. On error, the function returns -1, and the global variable errno is set to one of the following values: EAGAIN Too many threads EINVAL Invalid request - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".