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
