Magnus Hagander wrote:
> This is a lot like what I was planning to work towards with the
> refactoring of the forkexec code I promised to do for 8.1.
Cool. BTW, have we accepted that EXEC_BACKEND is the way we're going to
workaround the lack of fork() on Win32 for the foreseeable future? I
mean, it _works_, but it's slow, ugly, and complicates the code. If it's
the only workable option for Win32 support, then fair enough -- I just
don't know enough of the Win32 API to know if there's a better
alternative out there (short of using threads, which is of course not
really plausible).
> I was actually thinking of not passing these on the commandline at all,
> in order to avoid possible quoting issues etc (recall all the problems
> with the stupid commandline processing on win32). Instead moving it into
> a struct that is appended to the end of the backend variable file/shared
> memory.
Sounds good to me. Finding a cleaner way to pass data to the child
process than writing it out to a file would also be nice, if possible.
Again, I'm not sure what options there are on Win32...
> That was also what I was thinking. Let me know if you want to split the
> load somewhere :-)
Given that you're planning to work on this, I've scaled back my
ambitions. I'll send a patch to -patches that just cleans up fork() and
doesn't change the EXEC_BACKEND case. So fork_process() will:
- flush stderr/stdout
- save and restore the profiling timer if LINUX_PROFILE is defined
- handle BeOS
which means it should not be very invasive. Of course, there is plenty
of room for improvement -- if you're interested in taking a look, please
do...
-Neil
