public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* RE: How about a _beginthread implementation of fork?
@ 1997-11-12  7:20 Sergey Okhapkin
  0 siblings, 0 replies; 4+ messages in thread
From: Sergey Okhapkin @ 1997-11-12  7:20 UTC (permalink / raw)
  To: gnu-win32, 'vischne@ibm.net'

vischne@ibm.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?

Two threads will use _one common_ data segment. Forked processes should have separated data areas.

-- 
Sergey Okhapkin, http://www.lexa.ru/sos
Moscow, Russia
Looking for a job.


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: How about a _beginthread implementation of fork?
  1997-11-12  0:08 vischne
  1997-11-12  7:40 ` Fergus Henderson
@ 1997-11-12 13:39 ` Chris Faylor
  1 sibling, 0 replies; 4+ messages in thread
From: Chris Faylor @ 1997-11-12 13:39 UTC (permalink / raw)
  To: gnu-win32

In article < 199711120808.IAA08724@out4.ibm.net >,  <vischne@ibm.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 <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
easy?
-- 
http://www.bbc.com/	cgf@bbc.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@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: How about a _beginthread implementation of fork?
  1997-11-12  0:08 vischne
@ 1997-11-12  7:40 ` Fergus Henderson
  1997-11-12 13:39 ` Chris Faylor
  1 sibling, 0 replies; 4+ messages in thread
From: Fergus Henderson @ 1997-11-12  7:40 UTC (permalink / raw)
  To: gnu-win32

vischne@ibm.net writes:

>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?

I don't think so.  fork() gives you two copies of the C stack,
and copies of global variables (including those used by the
standard library, e.g. environ, stdout, etc.), and two copies
of OS-related data structures (pids, signal handler tables, etc.).
Offhand I don't know exactly what _beginthread() does,
and I don't have the appropriate documentation on hand,
but generally threads share the same global variables,
and the child thread gets an empty stack, not a copy of
the parent's stack.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 4+ messages in thread

* How about a _beginthread implementation of fork?
@ 1997-11-12  0:08 vischne
  1997-11-12  7:40 ` Fergus Henderson
  1997-11-12 13:39 ` Chris Faylor
  0 siblings, 2 replies; 4+ messages in thread
From: vischne @ 1997-11-12  0:08 UTC (permalink / raw)
  To: gnu-win32

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;
}


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~1997-11-12 13:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-11-12  7:20 How about a _beginthread implementation of fork? Sergey Okhapkin
  -- strict thread matches above, loose matches on Subject: below --
1997-11-12  0:08 vischne
1997-11-12  7:40 ` Fergus Henderson
1997-11-12 13:39 ` Chris Faylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).