What Happens When You Run a Program

does running a program from a network file run the program locally?

Java will try to open the file C.jar from the U:\automation\ directory. It does not care whether this is a network share or local file - this distinction is made by the operating system (i.e. Windows) when Java requests it to read that file. The same applies for starting the executables.

This means that your event (1) is the most accurate description, however "download" does not necessarily mean that the whole file is copied to some download directory.

What exactly happens when you run a .NET executable (step by step to the point where the program is loaded and running)?

There's a reason that this information isn't easily accessible - because Microsoft have learnt that as soon as you publish anything it suddenly has to remain fixed for all time (source: 90% of Raymond Chen's blog).

The ECMA standard is available from here, though it appears from the table of contents that it may not cover the material you are after. It certainly specifies the structure, though probably not internal implementation details.

For specific internal details, you need to provide at least the exact version of the .NET Framework you are interested in (and we'll ignore other CLRs such as Mono) and the details of the program you are running.

If you have a practical (ie. debugging) reason for needing these details, start your executable with windbg and step through the loading process. (This will also work for interests sake, though it may not be as enjoyable.)

Finally, Mono is open source, so you can browse their code to see how they chose to implement it. There is obviously no guarantee that it is identical to the way Microsoft implemented theirs, but as an academic exercise either should be sufficient.

when I run the program for the second time it doesn't give me correct execution time

This problem is called "warmup": When you want to do performance test some code, you need to run the code several times (say, 10 times). Then you run it 100'000 times and measure how long it takes and divide that by 100'000 to get the average. A single measurement of the runtime is useless, unless the runtime is at least one minute.

The reason for warmup problems is that modern OSs and languages do all kind of tricks to make your code execute faster. For example, the call to Encryption() might actually invoke a function in a shared library.

Those libraries are loaded lazily, i.e. it's loaded the first time when your code actually calls the function. When it is loaded, the OS keeps it in a cache since chances are someone will need it again.

That's why the first few runs of an application have a completely different runtime than the next 10'000 runs.

Can you run an independent instance of a program from within Go?

In order to achieve it you need to replace exec.Command call with os.StartProcess giving extra process attributes os.ProcAttr and syscall.SysProcAttr. Setting flag Setpgid and leaving Pgid with default value of 0 achieves to goal as mentioned by @that_other_guy.

package main

import (
        "fmt"
        "os"
        "os/exec"
        "syscall"
)

func main() {
        cmd, err := exec.LookPath("sleep")
        if err != nil {
                panic(err)
        }
        attr := &os.ProcAttr{
                Sys: &syscall.SysProcAttr{
                        Setpgid: true,
                },
        }
        process, err := os.StartProcess(cmd, []string{cmd, "1m"}, attr)
        if err != nil {
                panic(err)
        }
        fmt.Println(process.Pid)
        process.Release()
        for {
        }
        return
}

---

Related Topics