On 6/15/2016 7:42 PM, Bill Zissimopoulos wrote: [snip] > WinFsp consists of an FSD (file system driver) and a DLL component. The > WinFsp DLL uses the Windows heap functions to manage memory > (HeapAlloc/HeapFree). It seems that the Windows heap is not properly > cloned after a fork, which leads to the crash I am experiencing. I have > the following questions: > > (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. Unix software usually requires no porting, or very little to account for libc implementations (glibc in Linux, newlib in Cygwin), and the Windows environment. I think you have 2 options: 1. Keep the Windows port and use the cross-compiler tools to create Windows native binaries. That means: forget about fork, start using the spawn family of functions, i.e. _wspawnvp. Of course the result will work independently of Cygwin, daemons are called services (and created differently). 2. Keep the base Unix version for everything. Fork/exec works fine, daemon works fine but you'll have to use cygrunsrv to install the daemon as service. You should read the documentation: https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-ansiclib Hope this helps. -- René Berber -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
