2

Say I compile some code and make it run. It will take 10 minutes to finish.

In the meantime, if I change some parameters in the code and compile it again using a separate terminal window and run it too (so there's now two programs running simultaneously using the same code), does the second run affect the first running program as the first compiled output is replaced by the second compiled output?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Mahesh
  • 556
  • 1
  • 3
  • 16
  • 1
    You won't even be able to compile the second unless you build an executable with a different name. Aside from that unless you're using some sort of shared memory approach each would get their own chunk of RAM. – Alan B Dec 09 '21 at 16:25
  • 1
    On Solaris, in about 2003, it would always crash if you did that IIRC – Mark Setchell Dec 09 '21 at 16:25
  • The compiler will try to write an executable file, that is running, and the compile will fail. Why not make this a runtime parameter, and run the same executable twice, with different inputs. – Mansoor Dec 09 '21 at 16:26
  • 4
    On Linux, the old program keeps running the old code, the new program runs the new code. – j6t Dec 09 '21 at 16:26
  • @j6t I'm using the linux – Mahesh Dec 09 '21 at 16:27
  • 1
    If you are using linux and don't take precautions not to overwrite content of existing file under execution then yes, running program may get screwed in unexpected ways. – user7860670 Dec 09 '21 at 16:27
  • @user7860670 your comment contradicts Sneftel's answer below. However I don't know who is actually right. – Jabberwocky Dec 09 '21 at 16:29
  • I don't think compiler does anything special than you manually overwrite the file. – apple apple Dec 09 '21 at 16:29
  • I'm right... Unlike Windows, linux does not usually enforce file locking and it is totally possible to change existing executable while it is still running leading to unexpected behavior. – user7860670 Dec 09 '21 at 16:30
  • @user7860670 What kind of unexpected behavior? – Mahesh Dec 09 '21 at 16:33
  • Unexpected behavior such as random crashes. – user7860670 Dec 09 '21 at 16:34
  • guys not getting the convincing answer :,) – Mahesh Dec 09 '21 at 16:35
  • IMHO, I would expect an operating system to mark an executable file as "read-only" while the executable is running, or some operating systems may make a copy of the executable before running it. – Thomas Matthews Dec 09 '21 at 16:36
  • @ThomasMatthews Windows actually keeps executables open as long as they run, so you can't mess with them. For Linux I don't know, but copying the code in memory once and for all before running would look reasonable. – Jabberwocky Dec 09 '21 at 16:38
  • @Rohit: Which linux? That matters. – Bathsheba Dec 09 '21 at 16:40
  • @Bathsheba Debian GNU/Linux10 (buster) – Mahesh Dec 09 '21 at 16:42
  • I just tested it on openSUSE Leap 15.2: it's like I said: old runs old code; new one runs new code. – j6t Dec 09 '21 at 16:43
  • 3
    Related: [Replacing a running executable in linux](https://stackoverflow.com/q/1712033/10077) – Fred Larson Dec 09 '21 at 16:44
  • @j6t: What happens if you have a fork? – Bathsheba Dec 09 '21 at 16:47
  • 2
    Also related: [Compiling a program while it is running](https://stackoverflow.com/q/12040994/10077) – Fred Larson Dec 09 '21 at 16:50
  • @Bathsheba Sorry, I don't know. But but my guess would be that since a fork only duplicates the process's memory (via reference counts), the fork would keep running the old code. – j6t Dec 09 '21 at 16:51
  • To be sure you should do this: 1. Compile to executable E1. 2. copy the executable E1 to E2. 3. Run E2. Now you can compile again yielding E1 which won't be a problem on any platform because E2 is totally independent from E1. – Jabberwocky Dec 09 '21 at 16:51

3 Answers3

2

The behavior isn't defined by the C++ standard. In general, one of two things will happen (depends primarily on operating system)

  1. The second compilation will fail because the linker won't be able to open the executable file to write to it.

  2. Compilation will succeed, and existing invocations of the original executable will be unaffected; later invocations will use the new executable.

The third possibility -- the compilation succeeds, and messes up existing invocations -- is unheard-of in modern operating systems.

Sneftel
  • 40,271
  • 12
  • 71
  • 104
  • There is not issue with the compilation. But I do not understand how first program is running using the updated output file. – Mahesh Dec 09 '21 at 16:30
  • Comments from user7860670 suggest that the assertion _"existing invocations of the original executable will be unaffected"_ is wrong. I do actually not know... – Jabberwocky Dec 09 '21 at 16:33
  • If they have concrete evidence of that, I'd defer to it... it wouldn't match my personal experience or my understanding of how the loader maps executables into memory, but I don't have firm evidence to back my experience up. – Sneftel Dec 09 '21 at 16:35
  • @Sneftel Would it make difference if cmake is used for building and compiling? – Mahesh Dec 09 '21 at 16:38
  • @Rohit No, it wouldn't. – Sneftel Dec 09 '21 at 16:42
2

The only reasonable answer is that the behaviour is entirely contingent on the operating system: the C++ standard makes no attempt to describe what could happen.

You operating system vendor might extend the common courtesy of documenting or specifying the behaviour but I've never seen such documentation.

Your best bet is to not attempt this.

I'm an old cat, here are some musings. It's unlikely you could do this on Windows due to file locking. On Sun workstations it's possible but the program doesn't seem to work well at all once you compile into the same location as a running executable. Well it was certainly like that when I was at University using pre-standardised C++. It simply behaved oddly and there's no accounting for it. On rhel it seems to work nicely for small programs in particular.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
2

There are three possible scenarios:

  1. On Windows, an executable file will get locked for writing and removal while it is being executed so the build will just fail.

  2. On Linux, an executable file is not necessary protected from modification or removal while it is being executed.

2.1. If a file is deleted from the file system and then a new file is created with the same name then the old file content will still remain until already running executable exits while the new executable will use the new file. So the old executable will continue to run normally while the new one will be ready to work as well.

2.2. If a file is opened for writing and overwritten with new content then the already-running executable will be using the new machine code which is most likely be incompatible with the existing program state and will lead to crashes.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
user7860670
  • 35,849
  • 4
  • 58
  • 84
  • Note: Scenario 2.2. usually happens when you copy executable from build folder to some work folder as a post-build step. So one must take precautions and always try to delete existing file prior to copying new one to avoid random crashes. – user7860670 Dec 09 '21 at 16:47
  • Note: Scenario 2.1 can be problematic as well. For example: you want to debug some running executable after new executable file has been created; you start gdb and perform usual sequence `file attach ` and all of it sudden gdb prints confusing complaint that executables mismatch and no debug symbols available. – user7860670 Dec 09 '21 at 17:03