Open Bug 115903 Opened 22 years ago Updated 2 years ago

Each app should run in a separate process (Should be able to start "tasks" as different processes)

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: hans_k_97, Unassigned)

References

Details

(4 keywords, Whiteboard: [Hixie-3.0][MB]) 

There should be a way to start various mozilla components (i.e. browser, mail,
etc.- the things in the Task menu) in separate processes. (Apologies, my
thread/vm/process mgmt vocabulary isn't quite up to speed- I'm not sure if
"process" is exactly what I mean, since they do each get separate processes,
right? although starting a new browser instance attaches to the parent proc
rather than creating a new one.)

Currently if the browser crashes, it also takes out my mail client.  
current example behavior:
mozilla &
mozilla -mail &
ctrl-q (both are killed)

desired behavior:
mozilla &
mozilla -mail -noattach & // or something
ctrl-q (only the one with focus is killed)
Are you using the RPM builds?
yes- am I missing something obvious?
Just checking before assigning this bug to the guy who maintains the startup 
script in those builds.  :)

As a warning, running two separate mozilla processes on the same profile will 
currently result in problems (data corruption) if both processes attempt to 
write to the history database (and maybe the mail database).  You may be safe if 
you use one for mail only and one for browsing only, though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
oops.  forgot to reassign
Assignee: asa → blizzard
Sounds dicey. Making those resources safe for access/mutation by multiple
processes is probably a prerequisite.

This is something that's been annoying me lately: Mozilla and Galeon use
different caches and histories. I think that's silly. I've filed bug 134959 on this.


*** Bug 135176 has been marked as a duplicate of this bug. ***
Mail, Chatzilla, Navigator, XML Term, Calendar and Composer should each run in
their own process, with a shared Gecko/Necko library (to reduce the footprint
impact). Choosing File|Quit in each process should only affect that process.
Crashing in one process should also only affect that process. :-)

Special considerations need to be made about how IPC and IP hooks should work,
including URI handling (irc://, aim://, mailto:, news:, etc), the JavaScript
debugger, the DOM Inspector, and the Download Manager (how do we hand off a
download initiated from an HTTP POST?).
Severity: enhancement → normal
Component: Browser-General → XP Apps
Keywords: arch, footprint, highrisk, perf
OS: Linux → All
QA Contact: doronr → ian
Hardware: PC → All
Summary: [RFE] Should be able to start "tasks" as different processes → Each app should run in a separate process (Should be able to start "tasks" as different processes)
Whiteboard: [Hixie-PF][Hixie-3.0]DUPEME
Target Milestone: --- → Future
Whiteboard: [Hixie-PF][Hixie-3.0]DUPEME → [Hixie-PF][Hixie-3.0]
Depends on: 135137
Does this bug include the idea that each navigator browser instance (window) 
should also optionally be run as a separate process? Or would that be a new bug? 
This is a feature of IE that in earlier versions was an optional configuration 
and now just happens if you have sufficient memory. It's nice to only lose one 
browser window if something crashes.
It probably wouldn't be too hard to add that if the rest was implemented.
Whiteboard: [Hixie-PF][Hixie-3.0] → [Hixie-PF][Hixie-3.0][MB]
Fixing this bug would especially be useful for the download manager, see bug 131871
The View Source component should also be one of these separate components (as
per bug 145021).
Depends on: 145021
Whiteboard: [Hixie-PF][Hixie-3.0][MB] → [Hixie-3.0][MB]
No longer depends on: 145021
Is there a chance that this feature will allow us to isolate the browser from
plugin failures (by running plugins in a separate process)? If yes, then bug
36272 should be reopened.
Blocks: 36272
Aleksey: Running plug-ins in a separate process is an issue separate from both
this bug and bug 36272.
No longer blocks: 36272
Some thoughts about this bug:
Today if Mozilla is crashing we do not only lose the data in the crashed
component, but also in the other comonents running at crash time. So this is
also a dataloss issue.

If we can start a comonent as a seperate processe we would only have to check at
startup of it if it's already running, if not everythig is ok and we can start,
if it's already running the it depends...
...2 instances of MailNews eg are not good for our Mailboxes ;)
...2 instances of the dl manager also won't work together, because they use the
same files to store information about downloads, iirc
...but if Navigator is already running we could just open a new navigator
window, it would make no difference to the user.

Well, I don't know if every component is using it's own files/databases to store
its information, if not this could be a problem.
*** Bug 53945 has been marked as a duplicate of this bug. ***
*** Bug 130440 has been marked as a duplicate of this bug. ***
see bugs http://bugzilla.mozilla.org/show_bug.cgi?id=90293 and
http://bugzilla.mozilla.org/show_bug.cgi?id=34819

The first bug is about making a stand alone mailnews application.  The other bug
is about implementing altmail, which would allow the mozilla browser to still
have all the UI hooks for mail, news and addressbook.  But those UI hooks would
launch the default applications.  If the default application was the stand alone
mozilla-based mailnews app, we'd be done.
Having Mail run separately would not mean that we were done.

See comment 7 for a list of the apps that should be separated.  Separating Mail
alone would be insufficient (although a start).  Also, as per comment 8 and
comment 9, individual sessions of each application (including Navigator) should
run in a separate process.
*** Bug 176194 has been marked as a duplicate of this bug. ***
Would it help if configuration, profile, etc were handled be a separate process,
possibly running as a service/daemon?  I don't know how components currently
access this information, but if they do it directly rather than through an
interface, I guess it could represent a rather large change.  It seems to me
that if this was split off like this, start up times might be reduced and
profile management could be drastically improved.  I would imagine that it would
also make data corruption due to concurrency of a process per component easier
to manage.
Is this an issue of IPC, too?
IMO when parts of Mozilla were implemented in different parts, there'll be a
need of effective IPC between the components. 

Furthermore some common service-apps like a Profile-DB, or a UI-Server (X++)
would be a good thing. As mentioned in #20 already this could solve some other
problems.
However those common service-apps have a risk of crashing all components that
depend on them. Just like when your X-Server crashes, then your X-Programms will
die, too.
But if properly implemented this shouldn't be a unsolveable issue.

Finally such an implementation with different processes for different components
would enable Mozilla as a platform for a lot of OpenSource Projects like
FileManager, MediaPlayer, ...
There are already promising projects at mozdev but their usability suffers from
mozilla-apps running in only one process.
Product: Core → Mozilla Application Suite
Don't the availability of Firefox and Thunderbird obviate the need for this bug?
At this point, is it really thought that the suite will move in this direction?

(In reply to comment #22)
> Don't the availability of Firefox and Thunderbird obviate the need for this bug?

No. it's actually orthogonal to that.

> At this point, is it really thought that the suite will move in this direction?

At this point, it's not entirely clear in which direction the suite will move in
the long-time future. We know a short-time and a likely mid-term strategy but we
don't know where we want to go in the long term, so we also don't know yet if
this bug can still be considered valid or not.
yeah, I'd say this is won't fix...
It's still valid unless the component owner (not sure who that would be under
the new management) marks it as such.  At this point, I wouldn't mark *any*
Mozilla bug as WONTFIX - because it could just cause chaos when/if they start
being reopened after the changeover.  Let the new owners make that decision.
FWIW, there are a few reasons why FFox + Tbird != Moz Suite, even excluding
obvious ones like IRC & Composer:

1: memory footprint as mentioned in comment 7. Moz can share core resources
between components, whereas the standalone apps each load their own instances.
This could be solved alternately by separating out a complete backend library
which is called by any Moz-based app, but that's another bug entirely. I'd be
happy with either solution.

2: ease of administration. 1 suite is easier to install/maintain/update than 2
or 3 or more apps.
As a server-side programmer, I am tangling with the issue of people opening
multiple browser windows (in the same process) and getting the same
http-session information shared as a consequence.  In IExplore you can still
start the browser in a new process and hence get a fresh http-session and
consequently separated server-side session upkeep (or re-use the process with
ctrl-N and share the server-side session).  In Mozilla 1.7 / FireFox 1.07 there
is no facility to force a new process (and hence a distinctly separate
server-side session).  
I know that this is technically a different issue to that of starting different
processes in a multi-user environment, but while this issue is boing
considered, I would like to lobby for some help for the poor server-side
programmers who have to deal with this conundrum.
I would love to see a feature that allows users to choose to start the browser
windows according to their needs: same session, or distinct session.  I
suggested on a forum elsewhere that it would be ideal to have a setup option to
have Tabs start in the same process (and hence share serverside session
information), and Windows start in a new process (and hence NOT share
serverside session information).  At the UI level this would amount to a simple
pair of radio buttons in the "Prefs" "Advanced" area.
Alternatively or as well, it would be great to have a menu option like "New
Window" but "New Session".  Obviously this will baffle the punters to some
degree. 
That is of course if Mozilla can sustain being run in separate processes at
all.
I originally put this comment in https://bugzilla.mozilla.org/show_bug.cgi?id=247186
but I think this is more key to the issue ... other Bugs that seem related:
https://bugzilla.mozilla.org/show_bug.cgi?id=219984

Thanks for listening. 
 Rob
Whether or not the browser uses the same session is orthogonal to whether it is running in the same process. See the OSI layers to understand this.

http://en.wikipedia.org/wiki/OSI_model
(In reply to comment #28)
> Whether or not the browser uses the same session is orthogonal to whether it is
> running in the same process. See the OSI layers to understand this.
> 
> http://en.wikipedia.org/wiki/OSI_model
> 

Excellent!  Then may I extrapolate from that pearl of wisdom that it is in the browser software author's power to just engage a different http session that is naturally distinguishable from the server without any programmatic trickery, wherether or not the browser instance is in a new process / thread or whatever?
Is it therefore accurate to say that it has just been a chosen natural default that browser authors have opened a new http session when they've used a distinct process for a new browser window (eg: IE), and reused the same session when they've shared a process for browser windows?  (Obviously this is not necessary, just how it's been done in practice).
Given that this is true, I would say that my pleas for a feature that allows a user to deliberately open a distinct server-side "session" is not part of the "start browser in a new process" Bug or conversation.  I guess I'll start looking for it elsewhere, or start a new Bug ... ?
If nothing else hopefully this thread will be googleable and others trying to figure out their serverside code session problems will find it.

ignoring the fact that HTTP knows no sessions, you were probably looking for bug 117222. this bug is about the ability to run browser, mail and irc client (say) in different processes; not to launch several instances of the browser.
(In reply to comment #30)
> ignoring the fact that HTTP knows no sessions, you were probably looking for
> bug 117222. this bug is about the ability to run browser, mail and irc client
> (say) in different processes; not to launch several instances of the browser.
> 

Well, at least I'm learning a few things about some areas I've not been expsed to yet.  Thanks, for your corrections to my technical errors.
It stands that web-app server-side coders (I deal in j2ee, currently using Tomcat 5, Struts 1.2) can't naturallly distinguish between multiple browser windows open on a single client PC in Mozilla (or separately in Firefox, and likewise in IExplore windows opened via Ctrl-N.  Using (java) HTTPRequest request.getSession() returns the same object (and hence serverside cached state) irrespective of which specific window a request came from, and it's a damn pest for the serverside coder not to be able to distinguish which of multiple open windows on a clients box sent a request, as the user may have changed some fundamental context material in another window.
The only solutions on offer around seem to be to put in a single-use url variable to trace the identity of a window and trap attempts to reuse that variable by other windows.  I'm not especially happy about that means.
With respect, I don't think that my topic relates to mail and irc, though the technology may ultimately have concurrence.  Clearly I'm a minnow in these waters though so I don't want to assume too much about what I may or may not know.

(In reply to comment #30)
> ignoring the fact that HTTP knows no sessions, you were probably looking for
> bug 117222. this bug is about the ability to run browser, mail and irc client
> (say) in different processes; not to launch several instances of the browser.
> 

Ok, thanks for that steer Christian, now having read https://bugzilla.mozilla.org/show_bug.cgi?id=117222
... yes ... that IS the correct Bug for what I've been talking about.  What a travesty that Bug is!  You developers must hate it.  I feel sorry that I whinged and I can't help.
Anyone else who trips across this bug, look at 117222 before commenting any more here about what I was talking about.  It has loooong and intense history.
Sorry again for puluting this bug with comments.  This bug is only relevant in that it is by allowing new browser instances that IE manages to provide server-side session indepandance.
Thanks for your polite patience.
Cheers
 Rob
Assignee: blizzard → jag
QA Contact: ian
Target Milestone: Future → ---
Given the restrictions and assumptions that profiles impose upon us, I don't see this ever likely being feasible, do you?
Assignee: jag-mozilla → nobody
Flags: needinfo?
1. Make an option for network mode where you switch to a different profile location (just move the files to the local hard drive instead of the network drive). I would prefer to be able to have a different profile on every machine then have to only have one firefox open across my many log ins. I did every computer in the company I worked at with the same log in and just walked or ran around them all putting them to the next thing that needed to be done while everybody had gone home after work.

2. Evolve the profile. This would be more of a long term goal where you plan on changing the profile so it not only works better but also knows when and how to have multiple instances open. As I said not necessary for them all to be the same profile, it is for them to be able to open.

3. Make a separate version of firefox for network users that is on the channel page or just as a different project.  This would have a different profile system that can handle being on a network with more than one log in. Maybe your/were looking at this wrong. Maybe trying to change firefox is too big so making a separate project would allow you to do all the things you can't do because it wouldn't be good for most users.

Here's an idea. How about you start with option three and make a separate project so that you start the ball rolling towards the development of a working system.

Then you introduce that system back into the main firefox as an option in the network settings. This would make it easy to go between versions. Even if it took a while transferring between versions and had a giant warning if you tried to.

Then when your confident enough in this new method you could start mixing it into the main system as an experiment until you have it in the standard version which does both as seamlessly as if it were just one computer.

I don't care if this take many years but I don't want the community just to give up on it because nobody had the courage to think outside of the box.

Thank you for your time.
Flags: needinfo?
... I've commented on the wrong bug haven't I... I was thinking of the one that doesn't is only one log-in per domain network per log-in. As in a system where you log into the same user profile on multiple computers across a network you can only open firefox on one computer if your logged into multiple computers with the same user profile.

The people on that project just gave up and I've been trying to get them back on track. When I saw is it feasible I got a bit excited that somebody didn't just want to give up and go do something else so I wrote this up in a hurry.

On the other hand you could just imagine this method as potential method to fix this problem and many others.
You need to log in before you can comment on or make changes to this bug.