| 1 |
On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
| 2 |
> On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@×××××.com> wrote: |
| 3 |
> [snip] |
| 4 |
>> (Well, I'm not certain that POSIX thinks of threads as parents to each other. |
| 5 |
> |
| 6 |
> Hence the reason I put "parent" in quotes, and I specified "actually, |
| 7 |
> the thread that created it". |
| 8 |
> |
| 9 |
>> There are *numerous* IPC mechanisms available on Linux. For starters, |
| 10 |
>> there are sockets (domain, IPv4, IPv6, et al), named pipes, signals, |
| 11 |
>> mmap()'d files, messaging, etc. |
| 12 |
> |
| 13 |
> Yeah, none of them "easy and quickly" to use, or at least not if you |
| 14 |
> compare it with shared memory. |
| 15 |
|
| 16 |
I assume you mean 'shared memory' in the 'many threads to an address |
| 17 |
space', not the /dev/shm sense. |
| 18 |
|
| 19 |
> |
| 20 |
>> When one process writes to the chunk of its address space mapped to |
| 21 |
>> that file, the other process can immediately see those changes. All |
| 22 |
>> that remains is sending the other process a signal or some other |
| 23 |
>> driving mechanism to wake it up and have it look at that region for |
| 24 |
>> updates. |
| 25 |
> |
| 26 |
> Yup, certainly neither "easy" nor "quick". |
| 27 |
|
| 28 |
In C (or C++, or any language capable of directly manipulating mmapped |
| 29 |
regions), that's about as dead simple as it gets. Nothing else comes |
| 30 |
close to that degree of efficiency for that degree of simplicity. |
| 31 |
|
| 32 |
> |
| 33 |
>> dbus is only a 'little wonder' in that it provides protocol |
| 34 |
>> constraints and language bindings, which isn't really relevant when |
| 35 |
>> we're talking about same-address-space vs separate-address-space |
| 36 |
>> threading models. |
| 37 |
> |
| 38 |
> You right, of course; it has nothing to do with the discussion at |
| 39 |
> hand. Is just that I *really* like dbus, and I preferred it over |
| 40 |
> almost any other IPC mechanism in Linux. |
| 41 |
|
| 42 |
I know how much you like dbus. :) I just didn't care for the |
| 43 |
implication that it was the only mechanism of note. There are other |
| 44 |
extraordinarily important mechanisms. |
| 45 |
|
| 46 |
> |
| 47 |
>>> AFAIK, Google Chrome was |
| 48 |
>>> the first desktop program in Linux which uses several processes |
| 49 |
>>> runnning under the same GUI. |
| 50 |
>> |
| 51 |
>> Absolutely not. I used to play a game called 'realtimebattle' |
| 52 |
> |
| 53 |
> OK, I will rephrase it: Google Chrome is the first *relevant* desktop |
| 54 |
> program in Linux which uses several processes runnning under the same |
| 55 |
> GUI. |
| 56 |
|
| 57 |
Chrome was certainly the first *web browser* to take fault |
| 58 |
segmentation through separate processes that far. Before Chrome, |
| 59 |
Firefox used a separate process to thunk between the 32-bit Flash |
| 60 |
plugin and the 64-bit Firefox process on amd64 machines. |
| 61 |
|
| 62 |
Sticking with Desktop systems (so, not touching on SCADA), and |
| 63 |
sticking with Linux (so, not discussing the extensive use of ActiveX |
| 64 |
and OLE on Windows), we're left looking for some other multiprocess |
| 65 |
desktop applications. Here's a quick list of reasonably well-known |
| 66 |
ones: |
| 67 |
|
| 68 |
* VLC, ffmpeg and xine, which all used the xshm extension as a shared |
| 69 |
memory IPC mechanism to push video data rapidly to the X server (a |
| 70 |
separate process) |
| 71 |
* Everything in GNOME that ever used CORBA. I presume there was |
| 72 |
something similar for performing RPC calls within the KDE setup. |
| 73 |
|
| 74 |
-- |
| 75 |
:wq |
Archives