(jcwren) Re: Background processes in Win32

This would seem to be a fairly expensive operation, since each invocation requires a complete load of perl.exe, and the resulting compilation of the script. You will probably speed up the overall process, but with a heavier load cost to the system.

I don't know what the expense of changing to Win32::Process would be, but it's probably less than using eval() to spawn the process.

As much as I like Windows, this one paragraph makes for a lot of frusteration:

One of the largest areas of difference is in the process model. UNIX has fork; Win32 does not. Depending on the use of fork and the code base, Win32 has two APIs that can be used: CreateProcess and CreateThread. A UNIX application that forks multiple copies of itself can be reworked in Win32 to have either multiple processes or a single process with multiple threads. If multiple processes are used, there are multiple methods of IPC that can be used to communicate between the processes (and perhaps to update the code and data of the new process to be like the parent, if the functionality that fork provides is needed).

--Chris

e-mail jcwren
Comment on (jcwren) Re: Background processes in Win32

Replies are listed 'Best First'.
(c-era) Re: Background processes in Win32 by c-era (Curate) on Oct 23, 2000 at 17:26 UTC
That does work (overhead is not really in issue now, but it could be in the future). The problem is that if perl is not installed in the same spot on each workstation the program breaks. Anyone know of a way around this (other then installing perl in the same spot on each workstation)? c-era	[reply]
(jcwren) RE: (c-era) Re: Background processes in Win32 by jcwren (Prior) on Oct 23, 2000 at 17:40 UTC
There are a couple of solutions, of which the most elegant is to make sure that the directory containing perl.exe is placed in the system path. I imagine you know how this is done, but for others I'll iterate the process under WinNT 4.0. Start->Settings->Control Panel->System, select the Environment tab, click on System Path in the System Variables box, click in the value box, hit the end key, add ';d:\perl\xxx\bin', replacing that with the fully qualified path to the directory containing the Perl executable, click Set, then OK. If you're not an administrator on the system, you should be able to add it to the Path variable in the User Environments box. I've never been on a NT system where I'm not an administrator, so I'm not positive. A more hackish way is look at the Perl variable, $^X, although you're not guaranteed to get a path in that information. I believe you will under Windows, since argv[0] always contains a fully qualified path name, but you'd have to check that to be sure. --Chris e-mail jcwren	[reply]
(c-era) Re: Background processes in Win32 by c-era (Curate) on Oct 23, 2000 at 17:47 UTC
Same thing I told the_slycer, the PATH variable is set, but WIN32::Process::Create <bold>needs</bold> the full path to the perl.exe. I could hack $^X, but using eval would be simpler and easier to read at that point, and I'm not guaranteed it will work.	[reply]
RE: (c-era) Re: Background processes in Win32 by the_slycer (Chaplain) on Oct 23, 2000 at 17:35 UTC
You can install perl on a shared file-server, set the PATH environment on the workstations to point at the \perl\bin dir there, and make sure that everybody has the same drive mapped to the same place. This may be a little easier than installing perl on each station. HTH	[reply]
(c-era) Re: Background processes in Win32 by c-era (Curate) on Oct 23, 2000 at 17:40 UTC
Perl is already installed on each workstation, but not always in the same location. The PATH environment on the workstations point to perl\bin, but when using Win32::Process::Create you need to enter the full path to the excutable, if the path is wrong the program won't run.	[reply]