From: cgf AT bbc DOT com (Chris Faylor) Subject: Re: How about a _beginthread implementation of fork? 12 Nov 1997 16:31:28 -0800 Message-ID: References: <199711120808 DOT IAA08724 AT out4 DOT ibm DOT net> Reply-To: cgf AT bbc DOT com To: gnu-win32 AT cygnus DOT com In article <199711120808 DOT IAA08724 AT out4 DOT ibm DOT net>, wrote: >This is probably a naive approach, but is the following code an accurate >representation of how to implement fork() using the Windows 95 RTL C >library? If so, how much effort would be needed to redo cygwin.dll so as >to make fork() _not_ do anything to the cygwin environment? > >#include >#include > >void __forker__(void *); >unsigned long fork () >{ >/* Possible code for getting the return address of the fork() caller: */ > return _beginthread((_USERENTRY (*)(void *))forker, > 4096, (void *)NULL); >} > >void __forker__ (void *threadno) >{ >/* Possible code for inserting the return address of the fork() caller: */ > return 0; >} This is a naive approach. It does not, in any way, duplicate the functionality of fork. Sorry. A forked process on UNIX runs as a separate process and does not share the address space of the initiating process (unless we're talking about vfork which is slightly different). Once a forked process has been started it is a separate entity which can open new file handles and make changes to memory without affecting the parent. None of this is true for threads. And, think about it for a second. A lot of people have worked on the cygwin code. Don't you think that it is very likely that one of them would have stumbled across threads as a mechanism for duplicating fork functionality if it was this trivially easy? -- http://www.bbc.com/ cgf AT bbc DOT com "Strange how unreal VMS=>UNIX Solutions Boston Business Computing the real can be." - 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".