Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
From: "Gerrit P. Haase" <gerrit DOT haase AT t-online DOT de>
Organization: Esse keine toten Tiere
To: cygwin-apps AT cygwin DOT com
Date: Thu, 30 Nov 2000 07:21:40 +0100
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Subject: (Fwd) Re: sendmail on cygwin
Reply-to: gerrit DOT haase AT t-online DOT de
Message-ID: <3A260004.29959.4EBFD0E@localhost>
X-mailer: Pegasus Mail for Win32 (v3.12cDE)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id BAA04914


------- Weitergeleitete Nachricht / Forwarded message -------
Von:            	Gerrit P. Haase <gerrit DOT haase AT t-online DOT de>
An:             	Gregory Neil Shapiro <sendmail+gshapiro AT sendmail DOT org>,   sendmail-questions AT sendmail DOT org
Betreff:        	Re: sendmail on cygwin
Antwort an:     	gerrit DOT haase AT t-online DOT 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 DOT unnfr AT g-bayvar DOT qr' vs$_;