This is the mail archive of the cygwin-apps@sources.redhat.com 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]

(Fwd) Re: sendmail on cygwin



------- Weitergeleitete Nachricht / Forwarded message -------
Von:            	Gerrit P. Haase <gerrit.haase@t-online.de>
An:             	Gregory Neil Shapiro <sendmail+gshapiro@sendmail.org>,   sendmail-questions@sendmail.org
Betreff:        	Re: sendmail on cygwin
Antwort an:     	gerrit.haase@t-online.de
Datum:   	Sun, 26 Nov 2000 20:09:34 +0100

<26 Nov 2000, 10:37 Uhr wars, als Gregory Neil Shapiro folgendes
schrub:>
< Re: sendmail on cygwin >

> gerrit.haase> Maybe you got some hints for me how to manage it?
> Sorry, no.. Even if you could build it, it wouldn't work as Windows
> doesn't have a fork() call.

O.k., but cygwin is not windows, cygwin got a fork! So when it builds on
unix, it should build on cygwin too.

From the FAQs:

How is fork() implemented?
Cygwin fork() essentially works like a non- copy on write version of
fork() (like old Unix versions used to do). Because of this it can be a
little slow. In most cases, you are better off using the spawn family of
calls if possible.
Here's how it works:
Parent initializes a space in the Cygwin process table for child. Parent
creates child suspended using Win32 CreateProcess call, giving the same
path it was invoked with itself. Parent calls setjmp to save its own
context and then sets a pointer to this in the Cygwin shared memory area
(shared among all Cygwin tasks). Parent fills in the childs .data and
.bss subsections by copying from its own address space into the
suspended
child's address space. Parent then starts the child. Parent waits on
mutex for child to get to safe point. Child starts and discovers if has
been forked and then longjumps using the saved jump buffer. Child sets
mutex parent is waiting on and then blocks on another mutex waiting for
parent to fill in its stack and heap. Parent notices child is in safe
area, copies stack and heap from itself into child, releases the mutex
the child is waiting on and returns from the fork call. Child wakes from
blocking on mutex, recreates any mmapped areas passed to it via shared
area and then returns from fork itself.

------- Ende der weitergeleiteten Nachricht / End of forwarded message -------
gph

--
use Filter::exec qw(tr n-za-mN-ZA-M a-zA-Z);
@ = ("Whfg", "nabgure", "Crgre", "Unnfr,");
sbernpu $1 ( @ ) { cevag ( "$1", " " ) ; };
$_=1; cevag 'treevg.unnfr@g-bayvar.qr' vs$_;

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