On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mike...@gmail.com> wrote: [snip] > (Well, I'm not certain that POSIX thinks of threads as parents to each other.
Hence the reason I put "parent" in quotes, and I specified "actually, the thread that created it". > There are *numerous* IPC mechanisms available on Linux. For starters, > there are sockets (domain, IPv4, IPv6, et al), named pipes, signals, > mmap()'d files, messaging, etc. Yeah, none of them "easy and quickly" to use, or at least not if you compare it with shared memory. > When one process writes to the chunk of its address space mapped to > that file, the other process can immediately see those changes. All > that remains is sending the other process a signal or some other > driving mechanism to wake it up and have it look at that region for > updates. Yup, certainly neither "easy" nor "quick". > dbus is only a 'little wonder' in that it provides protocol > constraints and language bindings, which isn't really relevant when > we're talking about same-address-space vs separate-address-space > threading models. You right, of course; it has nothing to do with the discussion at hand. Is just that I *really* like dbus, and I preferred it over almost any other IPC mechanism in Linux. >> AFAIK, Google Chrome was >> the first desktop program in Linux which uses several processes >> runnning under the same GUI. > > Absolutely not. I used to play a game called 'realtimebattle' OK, I will rephrase it: Google Chrome is the first *relevant* desktop program in Linux which uses several processes runnning under the same GUI. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
