>> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
