James Gregurich wrote: > I want everything in a > nice, tidy black-box that the average joe is incredibly unlikely to > screw up.
Err, you don't have seventy five executables and expect the user to manually launch and click them. It is indeed all hidden. They see one window to one program, and the right thing just happens behind the scenes. > I have no idea what google chrome does and can't comment on > it. I don't use the app. I'd strongly recommend looking up articles about the internal architecture (using Chrome won't tell you much). Even if you reject it as a design pattern you should at least be aware of it. Some starters: http://arstechnica.com/open-source/news/2008/09/hands-on-with-chrome-googles-browser-shines-mostly.ars (overview in internals section) http://arstechnica.com/security/news/2008/09/chrome-antics-did-google-reverse-engineer.ars (down and dirty nuts and bolts of it) http://cr.yp.to/qmail/qmailsec-20071101.pdf (ideally read all of it, but especially section 5) > Beyond that, I don't see how that approach solves the problem you > point out. You still have concurrency going on with shared data > structures. The point is to send the data and all other information that needs to be worked on to that "helper" process. For example a web browser needs the HTML content, CSS styling and Javascript files all applied to each other to produce the final rendered document. That data is not shared or used concurrently. > You still have to implement serialization on the shared > data structures. There will still be some of that. For example in a web browser the master process would be keeping track of the child processes (per tab), but the goal is to have the absolute least amount possible. And by having the separate processes you know there is less sharing even in the face of programming mistakes. > The only thing you gain from that design over a > threaded design is an extra degree of resiliency in that a crashed > task won't bring down the app. On the downside, you have the extra > hassle and complication of IPC. Or if you read the links above and suitably drop permissions from the processes then you also gain a far greater degree of immunity from other issues - for example a security bug in an image library in a process that can only decode images would not be able to touch your file system, allocate too much memory, use too much cpu, do networking or anything else inappropriate to decoding an image. Things like testing get considerably easier since you can test single task helpers in isolation. You can also test other parts of your application with other cooperating processes being "mocks". You can do things like upgrading substantial parts of your application while it is running (probably not applicable to your application). Any suitably useful program these days will find that it gets data in increasingly diverse ways. Consider something like a simple document viewer which in the olden days pretty much only got fed trusted documents. Now the documents could come from email attachments and over the web. Embedded images and clipart would previously have come from Microsoft Office or similar, but now could have been copy and pasted from anywhere. (I assume you disallow images in your system or have code that cannot possibly be compromised by hostile image data :-) And as you mentioned, SQLite is a good library to use for data structures both within the process and between processes. But how many people even noticed that when used in a threaded fashion, it was possible for error messages to be deallocated if another thread caused an error on the same connection? That could lead to a crash or lots of string garbage. I was actually the first to notice and that was long after people started using sqlite in a multi-threaded way. That is why the third paragraph is in http://www.sqlite.org/c3ref/errcode.html and why sqlite3_mutex api was added in the first place! Threads are very hard to get right and require very good programmers, ideally ones who never have a bad day :-) Or as DRH simply put it - "evil". Roger _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
