Re: refactoring fork() and EXEC_BACKEND

>> 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 don't beleive there is any other way than using threads. The only
"objects" you can create are processes and threads, and I don't know
there to be any other way to create a process than CreateProcess().

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

Win32 already passes it using shared memory. It was when I asked to get
that patch in during beta (or possibly even RC) that I promised to work
on the cleanup stuff for 8.1. For unix/exec_backend it still writes to a
file, but since that is never expected to be used in production where
performance is an issue...

I think that is a fairly clean way of doing it. You could pass it
through a pipe or something, but I don't see that it would be a cleaner
approach. You're still going to have a single place collecting all the
data, which is where most of the uglyness comes from.

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

Ok. I'll look at it once your stuff is done.

//Magnus