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=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT 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>
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
Content-Type: text/plain; charset="utf-8"
Content-ID: <E808F52DC7D9A4489E9F5C462CCA0988 AT namprd07 DOT prod DOT outlook DOT com>
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
Content-Transfer-Encoding: 8bit
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