This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: Fork and Windows Heap


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


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