Skip to content
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

Open
nemequ opened this issue Jan 10, 2016 · 15 comments
Open

Support forking on Windows #2

nemequ opened this issue Jan 10, 2016 · 15 comments

Comments

@nemequ
Copy link
Owner

nemequ commented Jan 10, 2016

Windows doesn't support fork(), but there might be something similar enough for us to use…

@nemequ nemequ added the windows label Jan 10, 2016
@lygstate
Copy link

CreateProcess

@nemequ
Copy link
Owner Author

nemequ commented Jan 10, 2016

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…

@lygstate
Copy link

There is parameter to disable exec.

@nemequ
Copy link
Owner Author

nemequ commented Jan 10, 2016

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?

@nemequ
Copy link
Owner Author

nemequ commented Jan 14, 2016

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.

@lygstate
Copy link

@nemequ
Copy link
Owner Author

nemequ commented Jan 14, 2016

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.

@lygstate
Copy link

@nemequ I suggest do not only support for mingw, both mingw/ msvc need to be supported.

@nemequ
Copy link
Owner Author

nemequ commented Jan 14, 2016

Of course. Does winternl.h not exist for msvc? Based on line 16 I assumed windows had it but mingw didn't…

@s-u
Copy link

s-u commented Jan 15, 2016

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. forknt used to work, but it doesn't on more recent Windows releases (if I recall it started breaking in Vista).

@nemequ
Copy link
Owner Author

nemequ commented Jan 15, 2016

@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.

@vitasam
Copy link

vitasam commented Apr 13, 2017

Hi,
I don't want to create an issue, just a quick question: what is a correct way of running test application under Valgrind: with or without --no-fork option?

@nemequ
Copy link
Owner Author

nemequ commented Apr 14, 2017

@vitasam, it has been a while since I used valgrind (pretty much since AddressSanitizer came out), but IIRC you can pass --trace-children=yes to have it check child processes, or you can pass --no-fork to µnit so valgrind doesn't have to deal with it (though of course you lose the benefits that come with forking).

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.

@vitasam
Copy link

vitasam commented Apr 18, 2017

@nemequ, thanks!

@Snaipe
Copy link

Snaipe commented Feb 20, 2018

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! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants