Robert L Krawitz wrote:
>
> This sounds a lot like how shared libraries (and indeed, shared text
> in general) work, but it's not enough to solve the problem. If you
> run multiple copies of an application (on most UNIX-like operating
> systems, and even Windows is probably smart enough these days), there
> will be only one copy of read-only memory, and read-write data will be
> copied on write. That's strictly an efficiency issue, though; it
> doesn't change the programming model.
>
> Netscape actually runs only one instance, with multiple windows (and
> multiple threads sharing one address space). You'll note that if you
> try to start a second Netscape from the command line with one running
> you'll get a warning that it won't be able to use your history,
> certificates, or anything else. This is because Netscape isn't able
> to arbitrate between multiple instances modifying the same file
> concurrently (or even accessing it where one instance might change
> something). Multi-threaded programming is considerably more difficult
> than single threaded programming, and I guess Netscape decided to only
> go so far (make the application MT, but not arbitrate between multiple
> instances). The problem with MT programming, of course, is that if
> you get the synchronization wrong things blow up in your face, usually
> in very hard to debug ways.
>
Hello Robert,
Thank you for the explanation. I can understand the problem of saving
preferences if someone has several instances of an application open. Do
you know what Gimp does?
My preference would be to keep the preferences from the last instance
closed and just throw away anything from another instance unless the
user specifically applies the change to their profile. If someone had
open instance3 A and B, and manually saved a setting in A, I would have
an option to "save as default for future sessions. Instance B would
detect that there was a default set and not save over the top. If the
value is not flagged as a default, then B would write over it when B
closed.
The only instance I can think of where I would want multiple instances
updating each other, is when I create a new brush definition in once
instance, and want it immediately available in all others. I certainly
do not want to change the current selection in the others, which is one
problem with PSP.
In the Windows world, and a few others, people have a hard time because
they use objects and other techniques to make their code fuzzy. Like all
fuzzy logic systems, it is hard to see what is happening so is hard to
test. When they move an application from Windows to NT, the application
users start finding millions of errors caused by data mixed in with
code, data not defined as read data versus update, system data avaulable
for update by users and an endless list of similar style design and
coding faults. I worked on a number of projects to fix n-tier
applications by reducing them to 2-tier or 1-tier. If some of those
n-tier systems were buildings, they would have been building from the
roof down.
Do you know of a good, simple explanation of GTK? One that has diagrams
and stuff that can be read and understood without knowing C? If I had to
build a house using plans written in C, the electricity outlets would
produce water and touching a kitchen cupboard knob would turn all the
windows blue :-)
Peter
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer