James Gregurich wrote: > So, you suggest I should build a commercial desktop application (for > processing print-industry files and presenting them in a UI) in such > a way that it spawns multiple processes and communicates with them via > the filesystem or IPC APIs?
You obviously know more about your application, APIs, libraries etc but it does sound like it would actually be a very good approach. And of course you can also spawn processes on other machines too should the need arise. The description sounds not too different than what Google Chrome does. > Why would I want to go to that level of complexity in an > uncontrollable environment (i.e. a consumer desktop computer) when I > can just use NSOperation, boost::thread, and boost::mutex to build a > single-process solution that shares data in a normal way between tasks? Because while you are a perfect programming machine, not everyone else who will touch the code in the future is. As an example if one mutex call is left out or the wrong acquired by programming accident, how long would it take to know about it and fix it? If you have to run in a 32 bit address space then that also limits how much you can do in one process. Do you even know how large the maximum stack size is per thread and will other coders never exceed that? [Don't answer here - its your application, architecture and team :] Roger _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
