Re: Chrome processes vs. threads
- From: usenet@xxxxxxxxxxxxxx (Woody)
- Date: Fri, 19 Sep 2008 20:50:42 +0100
Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:
Woody <usenet@xxxxxxxxxxxxxx> wrote:
Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:[snip]
Woody <usenet@xxxxxxxxxxxxxx> wrote:
Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:
Woody <usenet@xxxxxxxxxxxxxx> wrote:
you certainly
wouldn't get that with multiple applications, and even if you could,
what would you gain from doing that - how would that actually
help the issue?
But unless you did something like that, then running multiple
copies of the browser would cause the browser to get its knickers
in a twist.
Why? You said that before but haven't said why. What would be the
problem sharing preferences that causes this?
Well, if (for example), you have two separate browsers trying to write
the `history' file with different ideas over what should be in it,
that'll cause problems.
Hardly. The issue of multiple applications writing to the same file is a
problem that was solved a long time ago.
So you think it's impossible for an application to get confused about
what the last page *it* visited was if another application has put a
more recent `last page visited' entry into the history file?
Of course it is not impossible. There are always the options that it is
written very badly.
In a
system design which assumed that only one app would be writing the file?
Why would that assumption be made?
Of course it'd get confused - you'd have (e.g.) two different copies of
the browser each claiming to have visited the pages the other had
visited.
No you wouldn't. Look at the history back button on your browser. See it
only has the places that that window has visited. Now open another tab,
and look at that history back. Notice how it is entirely unrelated to
the other tab in the same machine.
Now look at the history page, and notice how it has both interleaved.
Do you think that happens by accident? is one tab confused over where it
has been?
I'm not talking about file system issues: I'm talking about confusion
over the semantic contents of the files, such as outlined above.
Which would not happen.
Do you think that when the firefox people worked out the preferernces
system on firefox, they changed the way the mac system worked becasue
you couldn't run multiple browsers like you could on windows? no they
used the same system.
As I said, this is routine on windows and doesn't cause a prefs problem.
i can't see any reason why it would cause a prefs problem on the mac.
Mac apps are not designed to work that way.
There is no reason they couldn't be, or any reason it would cause a
problem on the mac.
Maybe not, but they are in fact not so designed and that's the current
situation.
OK, so no problem changing it.
In fact with the mac preferences system, it would be
fairly easy, although it is fairly easy on windows too. In neither case
do you actually have control of the preferences 'file' itself.
So what? What might be done has nothing to do with what we have now.
So you are saying it can't be done because we haven't done it?
'So what' is that your point was that it would be hard to impliment,
which it clearly isn't.
browser.And once you'd run out of different browsers to open pages in,
you're stuffed.
I was refering to running different instances of the same
But that won't work properly.
Why wouldn't it?
Because of the tangled prefs problem.
Which you haven't explained why it would exist. I really can't see any
reason for a problem with prefs, so I need it explained what the problem
is.
How about the above?
Its a non issue. There is no problem writing to a file.
It's a serious issue which you have failed to understand. I'm not
talking about file system issues, I'm talking about file contents
issues.
Which you have failed to demonstrate it being an issue, which is clearly
demonstratably not an issue under any circumstances, and is based on a
misunderstanding of how things work on your part.
It is certainly more isolated than the Google Chrome method.
But the browsers aren't designed to work like that, and they will get
confused over the prefs.
I thought the idea was to change the way browsers were designed.
Well, yes - but I'm talking about your suggestion that my idea can be
done now without re-writing the browsers at all, without having to do
anything at all except launch things multiple times.
OK, even so then, it is routinely done on windows now, with no
preferences problem at all.
Yes, but that's because the apps are designed to work that way while Mac
apps are not.
So firefox and safari are rewritten to work badly on the mac, rather
than when they is running on the PC when they don't have that issue?
It tends to be not done on the mac as you
wouldn't have multiple copies of the same browser running, but you can
have multiple coppies of other software running using the same
preferences. It really isn't an issue on either type of machine and
hasn't been for a very long time, unless the software is written to
cause a problem.
Since software authors usually make no attempt to deal with the problem
of two different copies of one application writing different things to
the preferences files and then getting confused because of this sort of
problem:
How do you have any idea what software authors make attempts to deal
with? You don't seem to understand what a trivial problem it is.
Program copy 1 writes data X -> prefs part A
Program copy 2 writes data Y -> prefs part A
Program copy 1 reads prefs part A, needs to find X, finds Y instead,
gets screwed up.
Why would it get screwed up, even if that happened?
what is 'X', and why does it need to find it. If it already has X, why
on earth would it read it again?
Program copy 1 writes history item X.
Program copy 2 writes history item Y.
Program copy 3 starts and reads history X & Y. What is the problem?
Other than vauge X and Y, can you explain one situation where this could
cause a problem in the web browser case?
With the default preferences system (of either machine), even if the
files were in heavy use (which they aren't, and lets face it, it is very
hard to write a history item from two browsers at the same time, as you
can only use one at once), it wouldn't be a problem, as the mac itself
(or windows) writes the preference file in response to the application
telling it to set a preference. The application doesn't open the file
and read it itself.
You have failed to understand the problem.
I have completely failed to understand the problem. I cannot see a
situation where a problem would occur if 500 applications were writing
to the same preference file. Could you posibly explain it in real 'non x
& y' terms. ie, provide a 'use case' where this situation causes a
problem?
And again, no prefs problem is described.
Above?
That was a repeat of the statement, not an indication of a problem.
Yes, because I'd already explained it so I thought there was no need to
repeat myself.
You haven't though. You have said 'this is a problem because it is a
problem because I said it was a problem'.
However, you didn't get it so I tried again. See above - again, for the
same reason as before.
Yes, you have repeated your suggestion that it is a problem.
This is true, applications are very different on windows. However, I
don't see a reason why they couldn't be like that one the Mac,
If you try to launch a single copy of a Mac app a second time, you'll
just get switched to the version that you launched previously.
You will for most normal applications, allthough it doesn't have to be
that way.
No? Explain.
It is this way because the application scheduler makes it this way when
you run the command 'open Safari' for instance. If you ran it manually..
actually lets try it.
Fire up safari by the normal method. The open terminal and type
/Applications/Safari.app/Contents/MacOS/Safari
I get this junk:
2008-09-19 20:38:05.150 Safari[1815:10b] Safari extension disabled:
unsupported browser bundle version '5525.20.1', only 412-5523.6 are
supported.
2008-09-19 20:38:05.585 Safari[1815:10b] *** CFMessagePort:
bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port =
0x7d03, name = 'com.apple.Safari.ServiceProvider'
See /usr/include/servers/bootstrap_defs.h for the error codes.
And safari bounces to life. I now have two copies running:
<http://skitch.com/woody/sp5y/two-safaris>
Navigate around, visit sites, hmm.. both seem to work fine. Close and
open, history works as you would expect.
You can make a copy of an app and run it separately and that works in
many cases - but I'd not expect it to work well in the case of a Web
browser because of the complexity of what it does with prefs (the
history, and stuff like that).
Again, no problem with prefs, absolutely no complexity at all, forget
about this, the only issue is in your head.
Absolutely a problem with prefs, forget about the idea that there are no
problems, you need to think more carefully, open your mind, and try to
understand.
I think you need to realise you thinking appears to be stuck quite a
long way in the past. But obviously, if you can find this prefs problem
I would be interested to hear how to create it.
now I have demonstrated how to fire up two safaris I guess you will be
able to show how this problem occurs?
I can see at a brief play with these things that they aren't actually
reading the prefs as they go along, which is what would be expected.
--
Woody
www.alienrat.com
.
- Follow-Ups:
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Re: Chrome processes vs. threads
- References:
- Chrome processes vs. threads
- From: Richard Tobin
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Re: Chrome processes vs. threads
- From: Woody
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Re: Chrome processes vs. threads
- From: Woody
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Re: Chrome processes vs. threads
- From: Woody
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Re: Chrome processes vs. threads
- From: Woody
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Re: Chrome processes vs. threads
- From: Woody
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Re: Chrome processes vs. threads
- From: Woody
- Re: Chrome processes vs. threads
- From: Rowland McDonnell
- Chrome processes vs. threads
- Prev by Date: Re: dashboard on cli ?
- Next by Date: Re: Chrome processes vs. threads
- Previous by thread: Re: Chrome processes vs. threads
- Next by thread: Re: Chrome processes vs. threads
- Index(es):