-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support forking on Windows #2
Comments
CreateProcess |
My understanding is that CreateProcess is like to fork+exec, not just fork. The documentation seems to confirm, but I really don't know Windows; maybe there is a way to use it in a more fork-like fashion… |
There is parameter to disable exec. |
Hm, maybe I'm looking for the wrong keywords, but I don't see anything in the MSDN docs about that. Can you be more specific? |
AFAICT the best solution available is to use some undocumented APIs from NT (ZwCreateProcess or NtCreateProcess, I don't know which is preferred). The best thread I can find on the subject is hardly conclusive. I'd be happy to merge a patch, but I'm probably not going to be writing this code myself; I don't really have a good way to do any development on Windows, and I'm not sure mingw will work for this. |
Nice. Seeing a full example instead of just a description helps. It looks like that project is GPLv2. I could rewrite the code, but @s-u, would you mind licensing us a copy under the MIT license instead? Modern versions of mingw seem to support winternl.h, so I think it should be possible to get rid of most (all?) of those types and typedefs. |
@nemequ I suggest do not only support for mingw, both mingw/ msvc need to be supported. |
Of course. Does winternl.h not exist for msvc? Based on line 16 I assumed windows had it but mingw didn't… |
Sure, I have added explicit MIT license (with non-binding copyleft) to the original file: https://github.com/s-u/multicore/blob/master/src/forknt.c But please keep me posted if you get it working - a lot of people would be very thankful. |
@s-u, thanks, I really appreciate the license change! I like that non-binding request, I'll have to think about adding that to µnit… I'll try to play around with it a bit at some point, but I'm really not a Windows developer so don't get your hopes up. Regardless, it's a good starting point for anyone else with the desire to tackle this issue. |
Hi, |
@vitasam, it has been a while since I used valgrind (pretty much since AddressSanitizer came out), but IIRC you can pass In the future, please file a new issue. It's actually much less disruptive since it won't cause notifications to be sent to people subscribed to the existing issue, and it helps keep the issues clean. |
@nemequ, thanks! |
I'm the author of Criterion, and it happens that I've been exploring the same set of issues since the inception of the project. While I started with simple forking, I ended up ditching the idea of just doing that two years later. The fact is that I've had myriads of problems with libraries that are not fork-safe (and most of them aren't. Looking at you, CoreFoundation) in general. Similarly, I've had my fair share of issues with windows, but ended up implementing the horrible pile of hacks that is fork on Windows; and let me tell you that without controlling the whole toolchain, this was horribly fragile and broke between windows releases. Instead, the new implementation forks, and re-executes the current executable while jumping on another main. All in all, this is just an order of magnitudes cleaner (in particular, since the parent's address space is not inherited, leaks from the parent don't propagate), but involves a lot of efforts to get somewhere. I understand that this might not follow the design goals of munit, so I thought I would give my two cents on the matter. BoxFort might not be for you, but you might get some ideas out of it. Good luck! :) |
Windows doesn't support
fork()
, but there might be something similar enough for us to use…The text was updated successfully, but these errors were encountered: