MSVC binary at http://xoomer.virgilio.it/hherold/ for public testing.
I performed only basic tests on NT4 sp6a, everything performed fine as
expected.
Some ideas on this thing:
In verbose mode the child should probably acknowledge in the log file the
fact it was invocated as child.
In debug mode the client should probably also log the name of the section
object and any information retrieved from it (currently the flag only).
In quiet mode the parent log (child pid, "log on wget-log" or whatever)
probably should not be printed.
A possible fix for the wgetrc race condition could be caching the content of
the whole wgetrc in the parent and transmit it in the section object to the
child, a bit messy I must admit but a possible solution if that race
condition is considered a Bad Thing. About the only scenario I could think
of is where you have a script creating a custom wgetrc, run wget, then
change the wgetrc: introduce -b and the script could change the wgetrc after
running wget but before the parsing on client side a rather remote but
possible scenario.
Heiko
--
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL PROTECTED] [EMAIL PROTECTED]
-- +39-041-5907073 ph
-- +39-041-5907472 fax
> -Original Message-
> From: David Fritz [mailto:[EMAIL PROTECTED]
> Sent: Saturday, March 20, 2004 2:37 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [PATCH] A working implementation of
> fork_to_background() under
> Windows – please test
>
>
> Attached is an implementation of fork_to_background() for
> Windows that (I hope)
> has the desired effect under both 9x and NT.
>
> _This is a preliminary patch and needs to be tested._
>
> The patch is dependant upon the fact that the only time
> fork_to_background() is
> called is on start-up when –b is specified.
>
> Windows of course does not support the fork() call, so it
> must be simulated.
> This can be done by creating a new process and using some
> form of inter-process
> communication to transfer the state of the old process to the
> new one. This
> requires the parent and child to cooperate and when done in a
> general way (such
> as by Cygwin) requires a lot of work.
>
> However, with Wget since we have a priori knowledge of what
> could have changed
> in the parent by the time we call fork(), we could implement
> a special purpose
> fork() that only passes to the child the things that we know
> could have changed.
> (The initialization done by the C run-time library, etc.
> would be performed
> anew in the child, but hold on a minute.)
>
> The only real work done by Wget before calling fork() is the
> reading of wgetrc
> files and the processing of command-line arguments. Passing
> this information
> directly to the child would be possible, but the
> implementation would be complex
> and fragile. It would need to be updated as changes are made
> to the main code.
>
> It would be much simpler to simply perform the initialization
> (reading of config
> files, processing of args, etc.) again in the child. This
> would have a small
> performance impact and introduce some race-conditions, but I
> think the
> advantages (having –b work) outweigh the disadvantages.
>
> The implementation is, I hope, fairly straightforward. I
> have attempted to
> explain it in moderate detail in an attached README.
>
> I'm hoping others can test it with various operating systems
> and compilers.
> Also, any feedback regarding the design or implementation
> would be welcome. Do
> you feel this is the right way to go about this?
>
> Cheers,
> David Fritz
>
>
> 2004-03-19 David Fritz <[EMAIL PROTECTED]>
>
> * mswindows.c (make_section_name, fake_fork,
> fake_fork_child): New
> functions.
> (fork_to_backgorund): Replace with new implementation.
>
>
>
>
