Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: Re: spawning Perl scripts

by BrowserUk (Patriarch)
on Mar 28, 2003 at 23:10 UTC ( [id://246558]=note: print w/replies, xml ) Need Help??


in reply to Re: spawning Perl scripts
in thread spawning Perl scripts

{grin} I could have antisipated that reaction:0

I guess I could categorise that under the "doesn't work like unix" heading. Although, at the fundemental level, the differences between forking the current process into two processes and then immediately overlaying that process with another process using exec as a mechanism for starting an asynchronous process is a little conveluted. No more so than forking a shell and have it start the asynchronous process I would add.

The nice thing about the Win32::Process route is that you ask the OS to start the asyncronous process for you with a single API call without the need for all the intermediate steps. I'm surprised that after all this time there is no similar create-an-asynchronous-process-running-this-command system call available under unix.

Does anyone know how this is acheived under other OS's, VMS/s390 et. They don't all follow the fork and exec model do they?


Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.

Replies are listed 'Best First'.
Re: spawning Perl scripts
by Abigail-II (Bishop) on Mar 28, 2003 at 23:31 UTC
    Well, one can of course dismiss everything under the "doesn't work like Unix" category. However, the "it works like Unix" way is what the OP wants. The "it doesn't work like Unix" way wasn't at all useful, as the parent process is waiting for its children to finish. Or at least, appears to. It wasn't the API that was complained about. It was the behaviour.

    Abigail

      However, the "it works like Unix" way is what the OP wants.

      Actually, I disagree with your reading of the OP's question there. S/he asked for a cross platform solution to starting an asynchronous process.

      Using fork and exec is one way of acheiving this, at least under unix, but it isn't the only way.

      I realise that portability isn't an issue for you, but as it seems to be for the OP, then he might be better off using

      system('command &'); on unix and

      system('start command'); on Win32

      And whatever the equivalent one-liner would be on his VMS systems, as the near-symmetry of the solutions on the different platforms would be much easier to manage than using the fork and exec model on unix and something different on the others.

      The problem arises because of the need to try and emulate a perl behaviour that derives directly from a unix system behaviour that simply doesn't exist in the other platforms. AS have done a pretty good job of the emulation under Win32, and it works well enough for many purposes, but not all.

      However, the lack of this unix feature in Win32 does not mean that Win32 is lacking the required facility--in this case the ability to start one asynchronous process from another--it just acheives it in a different, and one could say, more direct way.

      Ie.

      CreateProcess(command, ASYNCH); # done

      as opposed to

      newProc = CreateProcess(); CopyDataSegs(thisProc, newProc); newProc(command); BlowAwayCode&Data(); OverlayCodeFrom(command);

      That doesn't mean its better or worse, just different. Hence the question about VMS and s390. Which of the two models do they more closely resemble? Or do they have a third model? How good is the fork and exec model supported on those platforms.

      Using the system( 'start command' ); to start an asynchronous process actually comes down to remarkably similar set of steps as is used in the fork and exec model, and is neither hugely more or less efficient.

      The problem arises because perl mirrors the underlying unix system calls so closely, which makes porting it to any non-unix system difficult.That's not a critisism of either unix nor perl. Just a statement of fact. Had unix had a createProcessAsynch() system call rather than relying on the fork and exec model, the porting problems to other systems would have been simpler.


      Examine what is said, not who speaks.
      1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
      2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
      3) Any sufficiently advanced technology is indistinguishable from magic.
      Arthur C. Clarke.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://246558]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others taking refuge in the Monastery: (4)
As of 2024-03-28 21:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found