I posted a question about how to run an executable (a PDF viewer) under wine independently in multiple processes (independent means no communication between them, it is not parallel computing). I heard that the PDF editor (an enhanced edition of the viewer) of the some company can't do that.


  • So I wonder what makes an executable file able or not able to run independently in multiple processes?
  • Is it implemented by the program itself, by some libraries?
  • Can't OS make that happen?

2 Answers 2


This is almost certainly implemented by the program itself, and probably impossible for the OS to force for all but the most rudimentary programs.

If, however, you know the manner by which the program decides that it is already running, and that manner is something you can influence, then you can indeed get an executable to launch a new process (or not).

Some applications make this particularly easy, such as Emacs. The standard way to run Emacs is to launch a new process for each invocation. But you can also explicitly run Emacs in server mode and then run emacsclient explicitly to tell the existing server to visit a new file.

As an opposite example, Firefox offers a command-line option -no-remote that forces a new process to launch, whereas the default is to interact with a an already-running process if possible.

Many a simple home-grown application will check if another version of itself is already running by simply querying ps. This can be circumvented in a variety of ways. The problem with industrial strength software is that the user almost never knows how a particular application decides whether or not it is already in use. Even on Unix, where you can inspect all the open files with which an executable is interacting, there's no guarantee that you can figure out which one (if any of them) is responsible for recording the fact that the application is running.


A process is an instance of a program. A program can be instanced several times, that is, several processes can be created with the same executable code loaded. I would like to quote a line from Understanding the Linux Kernel by Daniel P. Bovet and Marco Cesati:

It is important to distinguish programs from processes; several processes can execute the same program concurrently, while the same process can execute several programs sequentially.

Basically, this means that while a program can be run in several instances, a single instance can only load one executable code at a time. So, starting from there, we could say that nothing prevents a program from running into multiple instances, because there is absolutely no reason to forbid it. Of course, these processes will not share anything but their execution code. Memory pages, file descriptors (which may concern identical files), and so on... are completely independent from one process to another.

Another point seems important to me when it comes to Unix-like systems (same book) :

Unix-like operating systems adopt a process/kernel model. Each process has the illusion that it’s the only process on the machine, and it has exclusive access to the operating system services.

Indeed, this is why Unix systems are multiprocessing/multiprogramming, or at least, it is the policy upon which this feature is based. So, due to this very fact, there is no way for a process to natively know that another process, running the exact same code, is waiting, or working on another CPU.

However, each process knows one thing: the system is being run by the kernel, and the kernel's services are at the process' disposal for all the time it'll spend working on a CPU. Thanks to this, it is possible for a process to query the kernel about other processes running as instances of the same executable. The first solution that comes to my mind is to read the /proc virtual filesystem. This FS acts like an interface between the user/application and the kernel (since these files represents kernel structures and data). In this filesystem, each process is given a directory (named with its PID), and within this directory, you will find a link called exe. For instance, here is my bash process' directory, PID 22343:

lrwxrwxrwx /proc/22343/exe -> /bin/bash*

Now, by browsing the filesystem, you will be able to find processes which are running the same executable code, that is, processes for which the exe link targets the same executable file.

However, since all Unix systems do not implement /proc the same way, developers aim to use a more portable solution, which relies on something pretty much all Unix systems understand: regular files. This is what .pid files are usually here for.

Most of the time, you will find these files in /run. For instance:

-rw-r--r-- /run/acpid.pid
-rw-r--r-- /run/atd.pid
-rw-r--r-- /run/crond.pid

These files are created by the application to which they belong, and used as markers of whether or not an instance of a program is running. Typically, the content of this file is simply made of the PID of the running process. In this case, I have a acpid process running, with PID 1503, and that's exactly what's in the PID file.

Now, since all processes of the same program share the same execution code, they share their constants (at least, their values). For this reason, if each instance knows where to look for the PID file, programming a single-instance program is quite easy:

if (the pid file exists) then
    send a signal to the running process or just bring it on the foreground
    exit since the work is going to be handled by the already-running process
    actually start the program, the first instance

Using signals in the first case is the behaviour I have seen the most, however, if your application uses some more sophisticated IPC (sockets, message queues, ...), you could use it to inform it that the user has requested something that it needs to do.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.