Fork and Windows Heap
Thu Jun 16 12:44:00 GMT 2016
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  seems to suggest so.
> > (2) Is there any workaround that the WinFsp DLL can use to get around
> > limitation and work properly after a fork? The obvious answer would be
> > have the DLL use Cygwin's malloc/free and this is indeed possible
> > 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
fuse_daemonize // do not allocate any non-Cygwin resources prior to
fuse_loop/fuse_loop_mt // safe to allocate non-Cygwin resources
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.
More information about the Cygwin