Re: [gentoo-user] Is my system (really) using nptl

[Volker Armin Hemmann]

Am Samstag, 13. Oktober 2012, 19:20:25 schrieb Michael Mol:
> On Sat, Oct 13, 2012 at 4:18 PM, Canek Peláez Valdés <caneko@×××××.com>
wrote:
> > On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol <mikemol@×××××.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.
>
> I assume you mean 'shared memory' in the 'many threads to an address
> space', not the /dev/shm sense.
>
> >> 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".
>
> In C (or C++, or any language capable of directly manipulating mmapped
> regions), that's about as dead simple as it gets. Nothing else comes
> close to that degree of efficiency for that degree of simplicity.
>
> >> 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.
>
> I know how much you like dbus. :) I just didn't care for the
> implication that it was the only mechanism of note. There are other
> extraordinarily important mechanisms.
>
> >>> 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.
>
> Chrome was certainly the first *web browser* to take fault
> segmentation through separate processes that far. Before Chrome,
> Firefox used a separate process to thunk between the 32-bit Flash
> plugin and the 64-bit Firefox process on amd64 machines.
>
> Sticking with Desktop systems (so, not touching on SCADA), and
> sticking with Linux (so, not discussing the extensive use of ActiveX
> and OLE on Windows), we're left looking for some other multiprocess
> desktop applications. Here's a quick list of reasonably well-known
> ones:
>
> * VLC, ffmpeg and xine, which all used the xshm extension as a shared
> memory IPC mechanism to push video data rapidly to the X server (a
> separate process)
> * Everything in GNOME that ever used CORBA. I presume there was
> something similar for performing RPC calls within the KDE setup.

yes, dcop. Which made it possible to script every kde app. It was also used 
for all those modules to talk to each other. Why they dumbed down to dbus - I 
don't know.
-- 
#163933