On Thursday, 23 May 2013 at 12:39:04 UTC, Vladimir Panteleev
wrote:
On Tuesday, 21 May 2013 at 04:52:25 UTC, Diggory wrote:
Either way, at least on windows the separate process would
have to be persistent as creating a new process has a lot more
overhead attached to it than on posix systems. Implicitly
creating a child process is also something a D programmer
might not want, again this is more windows specific where
processes do not have the same strict hierarchy as on posix.
What would be some of the potential downsides of a long-running
satellite process?
A concurrent GC would probably be opt-in or opt-out, either way.
You'd either have to distribute a separate .exe for the GC
process or embed the second .exe inside the first and extract it
at runtime to a temporary location, or call the same .exe with
some flag which tells it to turn into a GC. None of those options
are particularly nice, all of them require significant
interference from the GC, it's not just a case of calling some
function to start the GC. This is especially a problem in cases
where the runtime can't insert the init handler such as when
using WinMain, which you currently have to do unless you want a
console window to pop up.
Next there's the fact that you have a separate top level process
for every D process. This is going to cause problems with
security software since you now have to give both processes
permissions in order to run. In addition you have to consider the
case where one or other of the two processes is paused or killed
unexpectedly - you don't want orphaned GC processes hanging
around wasting resources.
