This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: How about a _beginthread implementation of fork?

In article <>,  <> 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 <stddef.h>
>#include <process.h>
>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
--			"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
"" with one line of text: "help".

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]