On Friday, 24 May 2013 at 07:48:49 UTC, Vladimir Panteleev wrote:
I don't know why you say that. The satellite process would be the same executable file as the main process, but started with a special switch (or environment variable), which will be handled by the D runtime. Since the two processes use the same image, the executable code will share the same pages in memory, resulting in a small overhead.
I'm fairly sure windows only shares memory between instances of the same DLL, not executables.
When implementing WinMain, you have to call the runtime initialization function, which will initialize the GC. GC initialization for the satellite process need not exit.
You're still executing part of the user's code and it's going to be exceedingly hard to satisfactorily explain why the main function will be called twice except the second time it will mysteriously stop half-way through because the runtime init function doesn't return...
I don't think this is true. Although the image subsystem is auto-detected by the entry point you're using (CONSOLE for main, WINDOWS for WinMain), you can specify it explicitly using the /SUBSYSTEM linker switch (/SUBSYSTEM:WINDOWS).
The only time I've been able to get it to not show a console window is when using WinMain...
Sorry? Could you provide an example (with a specific security software package)?
Any security software with the active defense type stuff, Commodo does it for example. The things they ask you about vary and it's completely pointless IMO, but they do ask for permission for practically everything and with two processes that's twice as much to ask you about.
Anyway, my main point is that it's not the kind of thing you want to impose as standard on all D applications, there may be other problems it causes depending on what the program is for. If it exists at all it should be opt-in and the default should still be as performant as possible.
I've tried writing a generational GC for D that used page protection for write barriers a while ago. IIRC, I ran into performance issues (the page faults were rather expensive).
Hmm, it shouldn't really be much slower than the technique Leandro was using - both rely on the exact same number of page faults - and his results looked very promising.
