Re: Chrome processes vs. threads

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:

Woody <usenet@xxxxxxxxxxxxxx> wrote:

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:

Woody <usenet@xxxxxxxxxxxxxx> wrote:

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:

Woody <usenet@xxxxxxxxxxxxxx> wrote:

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:

Woody <usenet@xxxxxxxxxxxxxx> wrote:
[snip]

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.

Or written assuming that you only have one instance of the program
running, if that's how the computer you're writing the software for does
things.

You get the same results, but it's not because of bad programming, just
appropriate programming if it's on a Mac.

But if you are writing the same application for windows and the mac, and
implimenting the preferences the same way (as firefox does), why would
you deliberately change it so it doesn't work the same way on the mac?
It doesn't make sense.

In a
system design which assumed that only one app would be writing the file?

Why would that assumption be made?

Because that's how Macs work on the whole: you've got an application on
disc, you launch it, you get one application running.

The only way to get another running copy of the app that I know of is to
make a copy and run that.

Or run it from the terminal, like I demonstrated later in the thread.

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.

Huh? The history menu displays the same data in Firefox 2.latest no
matter what tab I'm looking at.

Of course it does, that is what it is supposed to do.
I said the history back button, the menu that appears from that.


Notice how it is entirely unrelated to
the other tab in the same machine.

Same machine? Erm?

Now look at the history page, and notice how it has both interleaved.

Erm, the data is `interleaved' wherever I see it.

Do you think that happens by accident? is one tab confused over where it
has been?

I don't know what you're talking about.

No, because you didn't read what I said and are looking at the wrong
thing.

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.

Ah! Yeah, okay, that'd do it.

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.

Did I suggest that there was? All I suggested was that some work might
have to be done; and that it's not safe to assume that the work doesn't
need doing.

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?

No, I'm saying that it would take work to do because the work that is
needed has not been done.

Certainly in the firefox case it has been done. In the safari case if it
hasn't (and remember safari also works on windows) it would be trivial
to do.

'So what' is that your point was that it would be hard to impliment,
which it clearly isn't.

No, my point is it'd take some work to deal with. You have just
invented the idea that I've claimed it'd be hard - that's pure fiction.

[snip]

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.

You don't seem to understand that I know how trivial 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',

Data.

What data? 'Data' is the same as saying 'X' or 'Stuff'. I mean, what is
this thing that you are writing. Is it a web address, a value for the
screen size, what?

and why does it need to find it.

Because it wants the data.

But it already has the data. It only needs the data again at startup.

If it already has X, why
on earth would it read it again?

If it doesn't need data from a prefs file, then the prefs file will not
be written.

It needs it when it starts, it doesn't need it when it is running.

Assuming a prefs file, we can assume that the app which
wrote it actually wants to read from it too.

It certainly does, but not as it is going along.

If an app doesn't need to read data from a prefs file, then having prefs
files at all is pointless. Since prefs files are commonplace, I assume
that there is usually some use to them.

There is a use, but whether one application or 500 are writing to it,
the only time the value matters is when one starts up, and at that point
it reads the latest data. It may not be the same data as one of your
other windows, but I don't see how it matters.


I'm just trying to describe the sort of hiccup I'm talking about. It's
an abstract explanation.

ok.

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?

Not off the top of my head, no. Why do you think that I could come up
with an example of the potential problem I've identified actually
causing a real problem in real life?

Because if you can't think of it creating a problem in real life I don't
know why you are so sure it would actually cause a problem in real life.

[snip]

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

Ah! I had no idea that was the way to do it. Yes, that gives me two
copies.

That is actually executing the binary manually. If you type 'Open
/Applications/Safari.app' you are just telling the application launcher
('open' in this case) to launch the application if it isn't already
running, otherwise bring it to the front and tell it to do the 'new
window' action.

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.

No it doesn't, because I don't have any expectations in that line.

ok, I will rephrase. History works as I 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.

I think you need to realise that you have completely misunderstood me
and that I get very annoyed at tossers like you doing that and then
insulting me, you extremely rude person you.

Ok, it is abuse time then. Rowland is wrong so he goes abusive. Go ***
yourself. I know you don't want to learn anything new, you just want to
go round telling people who do this sort of thing for a living how to do
it.

Twat.

Anyway, knew it would come to that, your posts always do.

--
Woody

www.alienrat.com
.