X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-id:content-transfer-encoding:mime-version; q=dns; s=
	default; b=AQLE0isxqQgkfd8LoYMu0P+3m+kCAzocqS7SXoTHuM0uol0Fc54xM
	NE3C0oCKPZlcpmA3llyutbxhp24VzaS37VTKtoyrhmfXdtZF5NJYVzVJ5yALNCJD
	REC0vEeZJfExtVsaG3kq3HhRaKYpveI0sqyT0fROjWjDSwa7gIQBTY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:content-type
	:content-id:content-transfer-encoding:mime-version; s=default;
	bh=/kCy/XmUzQxksH8FLROCRqoZYKE=; b=nx3/Tud+aI456pINb5qSwikQgr5O
	j7IBArIXWMJ/gQzxe/dtKmrkt6B2JMsJ8QMKCsqP0oVYOF8cCb36BPKTWpi6zI0b
	2OyOuOHdhQGJqaRc0vC9mwi16ZCqDxBXHUI13YbC4b2ZcXDzMupel1iTLf95Itvn
	SEnY+nvxJXAlpGc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.9 required=5.0 tests=BAYES_00,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Fork, ren, nogo, no-go
X-HELO:	na01-by2-obe.outbound.protection.outlook.com
From:	Bill Zissimopoulos <billziss AT navimatics DOT com>
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	Re: Fork and Windows Heap
Date:	Thu, 16 Jun 2016 06:37:26 +0000
Message-ID:	<D3879734.9284%billziss@navimatics.com>
authentication-results:	spf=none (sender IP is ) smtp.mailfrom=billziss AT navimatics DOT com;
x-ms-exchange-messagesentrepresentingtype:	1
x-ms-office365-filtering-correlation-id:	e6d5dedf-9e82-471f-5cf8-08d395b0aed7
x-microsoft-exchange-diagnostics:	1;CY1PR07MB2198;5:LYXaA4Ex1shPu1b4x/FMnWYuCg5pCCCEMsdWMx2XdLI9Jw51E72piSNWAaE2HfEAd0hsb1+jb6ZPbZv22hIe/zDtH8IyAGf6xZPYN/lNjjP/mUTLLwqkb11q+XcFvcY81EsNRSYmAxL4Fl5fp+MXww==;24:GI+YPwF5cdeBbMe8pwpS4ryH8HG1t4sHxzmZcS48Rgkj3mBZL69qk2v0Du7g0hOJvMD/D9+/hojpcEEeURdmNV0Y0GJyHdrk/2lwCzwhdrc=;7:kcgZ1Uc4wDVJz2wOUBjSqd5e6MKD3qUgF1ArFaZYKvOzMer0Giq3MEpV+ugb2APbc+az1ti+4xXi+End5Puq2513HUadURweJPXw5NEmjkyZ9AOf/OfAi+0lgmZh6JXjOFwg+qSAgHQfm6niSSRB/yZE0R2ppX37A+HUN/wgzI2lw7nwA7Nl08xG1kg5HpnaJysMgpMyvR4wLuZ998BMrg==
x-microsoft-antispam:	UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2198;
x-microsoft-antispam-prvs:	<CY1PR07MB21982A50554645D9DF70209BBC560 AT CY1PR07MB2198 DOT namprd07 DOT prod DOT outlook DOT com>
x-exchange-antispam-report-test:	UriScan:;
x-exchange-antispam-report-cfa-test:	BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041072)(6043046);SRVR:CY1PR07MB2198;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2198;
x-forefront-prvs:	09752BC779
x-forefront-antispam-report:	SFV:NSPM;SFS:(10019020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(110136002)(10400500002)(122556002)(11100500001)(107886002)(5002640100001)(2351001)(99286002)(86362001)(189998001)(66066001)(106116001)(106356001)(81156014)(102836003)(2501003)(105586002)(68736007)(8676002)(92566002)(5004730100002)(586003)(77096005)(3480700004)(3846002)(2906002)(97736004)(81166006)(8936002)(5008740100001)(1730700003)(3280700002)(87936001)(36756003)(6116002)(19580395003)(3660700001)(5640700001)(54356999)(50986999)(101416001)(450100001)(2900100001)(345774005)(94096001);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR07MB2198;H:CY1PR07MB2199.namprd07.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en;
received-spf:	None (protection.outlook.com: navimatics.com does not designate permitted sender hosts)
spamdiagnosticoutput:	1:99
spamdiagnosticmetadata:	NSPM
MIME-Version:	1.0
X-OriginatorOrg:	navimatics.com
X-MS-Exchange-CrossTenant-originalarrivaltime:	16 Jun 2016 06:37:26.6741 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader:	Hosted
X-MS-Exchange-CrossTenant-id:	21071be9-4f9a-413b-89ac-8353a5d2410a
X-MS-Exchange-Transport-CrossTenantHeadersStamped:	CY1PR07MB2198
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id u5G6buhW029911

Renà Berber wrote:

> On 6/15/2016 7:42 PM, Bill Zissimopoulos wrote:

> > (1) Is my assumption that Windows heaps are not properly cloned after a
> > fork correct? A 2011 post [2] seems to suggest so.
> > (2) Is there any workaround that the WinFsp DLL can use to get around
>this
> > limitation and work properly after a fork? The obvious answer would be
>to
> > have the DLL use Cygwin's malloc/free and this is indeed possible
>within
> > the DLL's FUSE layer, but not workable elsewhere.
> 
> Those are the wrong questions: you shouldn't be mixing Windows and Unix
> (SuSv4, Posix) APIs, and by your description you are trying a Windows
> port, mixing it with probably the base, and expecting it to work on
> Cygwin, that's a no-go from the start.

Thank you for your response. With all due respect however I think you have
given me the wrong answers/pointers.

I am not porting anything from UNIX. I have a Windows solution developed
using Visual Studio and the Windows Driver Kit that I am building a FUSE
compatibility layer for. My DLL is not a Cygwin DLL. It is a native
Windows DLL that also has a FUSE compatibility layer. I am taking pains to
make that FUSE compatibility layer available to both Win32 and Cygwin apps.

The answers to my questions are:

(1) Cygwin does not clone Windows heaps after a fork. [At least my brief
perusal of winsup/cygwin/fork.cc seems to indicate so.]

(2) The workaround is to avoid allocating resources that Cygwin cannot
account for (e.g. from the Windows heap) prior to daemon/fork. Luckily
this is possible in a FUSE file system design, because in general it looks
like this:

    fuse_new
    fuse_daemonize		// do not allocate any non-Cygwin resources prior to
this
    fuse_loop/fuse_loop_mt	// safe to allocate non-Cygwin resources
    fuse_destroy

I have now modified the WinFsp FUSE layer accordingly and tested it
against SSHFS. I am able to daemonize SSHFS and everything works
correctly. I therefore consider this problem solved for me.

Bill

- Raw text -