Alternative for executables / processes?

[Solar]

A rather strange idea I had this morning, and on which I would like to have opinions.

In a "traditional" machine, when you start an executable a second time, a second process of the same executable is set up. The executable is of course free to note that another instance is already running, and react appropriately, but that's strictly optional.

What if the runtime would consider each executable to be equivalent to one process instead?

If the executable is not yet running, it is started, and the command line options are given to the process using a specified protocol (callback, whatever).

If the executable is already running, instead of setting up a new process, the already running process of that executable is passed the new set of command line options using the above protocol.

This new set of option could tell a word processor to spawn a new document, or could change the configuration of a running webserver, or tell a resident "ls" command to process a new directory...

I'm not sure yet how that would impact the overall system... It would certainly encourage multithreading, and perhaps there are efficiency benefits to win here, but right now I can't really wrap my mind around it.

Opinions?

[bubach]

how would the OS know if the program supported that?
the program would have to have some way of telling the OS that it supports it.

[Solar]

We're talking about writing new operating systems, no? Let's for a second assume that all programs for your OS support it because it's the only way to get executed by the system. (You could, of course, introduce a "compatibility flag" or whatever.)

[Pype.Clicker]

several 'large' application already have something similar ... I'm thinking of Mozilla or ooffice, as well as most KDE application do so by having a ~/.<application>/lock.pid file that tells them if an instance of the program is running and send it a signal, etc. to make it fork another process (or just open another window ...

A smart program loader could also find possible shared pages of the running program ...

I know freeBSD keep the 'initial' data page when a process modifies it just after having it loaded from the disk for that purpose ...

[ASHLEY4]

I like the idea, But is there not security issue?.
ASHLEY4.

[Pype.Clicker]

What concerns me most with that idea is the data security against misbehaved instances of the program (i guess you had in mind of multithreading the processing within the sole process, hadn't you?) ... If one document processed by one application == one process, you should not fear to lose all your work by a bad command in one text processor window (just what is under that window). I find it extremely disgraceful to lose my Mozilla.Editor instances when the Mozilla.Browser crashes ...

At system security, you should probably at least have one process per 'user running the program' ...

- Would your approach really benefit over a smart enough disk cache ?
- All the instances of the same program will have to live within a single address space (iiuc), isn't that a problem for applications that have laarge requirements over the address space ?
- Is there so much communication among the multiple instances of the simple program to keep them all in the same process ... wouldn't (for instance) be more interresting to have a process that include the shell, the most common commands (like ls, cd, etc.) and a few interpreters (like perl, make, etc) as autonomous components ?

[Solar]

What concerns me most with that idea is the data security against misbehaved instances of the program (i guess you had in mind of multithreading the processing within the sole process, hadn't you?)...

Hmm... granted, having every document in its own address space would be beneficial... you could still make that an option. With a copy-on-write algorithm, you still would have only one copy of the executable in memory...

At system security, you should probably at least have one process per 'user running the program' ...

Uh, sure. (Was thinking monouser again, stupid me...)

Would your approach really benefit over a smart enough disk cache ?

Performance wise, probably not (if the disk cache is *really* smart). I'm just toying with the design beauty of it...

All the instances of the same program will have to live within a single address space (iiuc), isn't that a problem for applications that have laarge requirements over the address space ?

No - there would be only one instance of a given program (per user).

Is there so much communication among the multiple instances of the simple program to keep them all in the same process ...

It's basically a wholly different paradigm of how to handle executables - it's no longer a process image to load and run, but rather a service / server...

wouldn't (for instance) be more interresting to have a process that include the shell, the most common commands (like ls, cd, etc.) and a few interpreters (like perl, make, etc) as autonomous components ?

That's not what I meant, but a nice idea in itself.

[Candy]

Would your approach really benefit over a smart enough disk cache ?

Performance wise, probably not (if the disk cache is *really* smart). I'm just toying with the design beauty of it...

This system is really beautiful. If I may add, you could potentially make some default-project-code-base like a project template to use by people to implement this default-wise. It takes a lot of bugs out of code that is default.

As an aside, you might want to put that behaviour not in the applications in specific but in the shell. The shell gives the actual command to open a new process, so if you don't want that to happen cleanly, make the shell figure out the current existing process for this user and tell it to add this document as an open document. That would make it a minor kernel issue (requiring some form of message sending/receiving by the apps) and a major shell issue (the shell does the trouble). Gets the trouble in user space, nice and clean.

All the instances of the same program will have to live within a single address space (iiuc), isn't that a problem for applications that have laarge requirements over the address space ?

As far as I can see Solar's suggestion, it would allow a program to create a new program instance when called to open a file or window or something. That would fix this too, for the applications that want that explicitly.

Couldn't you create a different model of starting programs? Instead of the program being started and some thread created, and the OS jumping to the entry point, instead programs are loaded and jumped to the entry point without arguments, and then a message is sent with the information about the session that is requested.

In that way you don't do double work, and you even split up traditional process creation into multiple manageable and different parts.

An idea?

[Pype.Clicker]

I admit Solar's vision has something nice in it ... What i'm unsure about is whether it's a good idea to force *every* program in the system to work that way. Moreover, having the same program running for a long time makes it much more sensible to memory leaks, etc.

If i had to develop a system like this, i would be tempted to enforce 'recovery points' from which the 'component' (as it's not really a program anymore) can be restored in a well-known state, and a track of which blocks of memory are owned by which thread so that one can safely free all the thread's resources once the thread is done ...

[Solar]

What i'm unsure about is whether it's a good idea to force *every* program in the system to work that way.

You'll probably be forced to offer the traditional way jsut out of compatibility with software ports, anyway...

Moreover, having the same program running for a long time makes it much more sensible to memory leaks, etc.

Now that's nonsense. Either you *have* memory leaks, or you don't. If you have, your program is broken, whether the leak is big or small. Add to this that you don't know how long your software will run anyway. (The system I'm typing this on has a 'tail -f' running for weeks, now...)

If i had to develop a system like this, i would be tempted to enforce 'recovery points' from which the 'component' (as it's not really a program anymore) can be restored in a well-known state...

How about keeping the component and it's individual instanciations seperate? You could exchange the component without having to shut down the instances, and whether to give the instances individual protection or not would be at the option of the component...

I don't think it would be a major security issue. If you don't trust a component to honor the security of your data, you're doomed anyway.

Ah well. I think I'll keep this in the back of my head for a while...

[mystran]

On my Linux box, if I write "firefox someurl" I get a firefox with that URL, unless I already had one, in which case it simply opens another tab for the new url.

When I type "vim somefile" I get a gvim, unless one was already running, in which case it would just open the file in the existing editor.

It's just a question of adding the necessary support into the app. You'd need that support anyway if you wanted to handle command line arguments.

[Candy]

It's just a question of adding the necessary support into the app. You'd need that support anyway if you wanted to handle command line arguments.

but with this method the support would be a small breeze, so everybody making a simple app can do it, and people that know what they're doing are not wasting their time on yet another slightly different implementation with another bugset. Seems like a positive thing.

[Solar]

Also, I think that with current apps, a new address space is set up first, then the new process finds that there is already an instance running, sends a message to that instance and exits again.

The way I picture it, it would be the other way round: The running instance is detected first, and whether a new process / address space is set up or not is decided then. It just "feels more correct"...

[Pype.Clicker]

that could simply be a shell stuff ... The shell queries the list of processes to know if there's a process running the requested program, and if not, it creates it...

[Candy]

that could simply be a shell stuff ... The shell queries the list of processes to know if there's a process running the requested program, and if not, it creates it...

That's what I said.

As an aside, you might want to put that behaviour not in the applications in specific but in the shell. The shell gives the actual command to open a new process, so if you don't want that to happen cleanly, make the shell figure out the current existing process for this user and tell it to add this document as an open document. That would make it a minor kernel issue (requiring some form of message sending/receiving by the apps) and a major shell issue (the shell does the trouble). Gets the trouble in user space, nice and clean.