From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id DA4BD138010 for ; Sun, 14 Oct 2012 22:34:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 68DA621C015; Sun, 14 Oct 2012 22:34:39 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 81F4DE03E4 for ; Sun, 14 Oct 2012 22:33:12 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id jg15so1972347bkc.40 for ; Sun, 14 Oct 2012 15:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding:content-type; bh=XWBpALxSnIVlmCTCp8TrLbAZS8QEleY1FmNYSNY5MP0=; b=0W0L9psmCS7ritewtJ0VdYJLXMJ6zCIMplLlCX2iKNCkJ5w4crQUAxcZBuhCTN4iJS 5bCD9o3M44mT0bJiMrAUnYaXAHMoz6pHwc8I8HZ9+uQhlThc+5tIPabHPrOyuyFvrvJH w6w45/oSqeNwjEoy9BessDVmrYRlCYcVPC0A21OrgPGVujJY1PZ6dS5QKxs2Ya20iLkF rfKvz22CxK9WtrvCf7V8Y5NwMc0ZycYhPJmKX1curUpTlif9bwANsXoY9fjGeI8a5wY0 tgsZ+If441jba6FEjSwYbewWjwo4BUpfeIdCEg+ybjeNBOKGM8MKtK/h031vnsXTzi2+ Qa3g== Received: by 10.204.8.141 with SMTP id h13mr2629465bkh.54.1350253991424; Sun, 14 Oct 2012 15:33:11 -0700 (PDT) Received: from localhost.localnet (p4FC60D1C.dip0.t-ipconnect.de. [79.198.13.28]) by mx.google.com with ESMTPS id e3sm7288816bks.7.2012.10.14.15.33.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 14 Oct 2012 15:33:10 -0700 (PDT) From: Volker Armin Hemmann To: gentoo-user@lists.gentoo.org Cc: Michael Mol Subject: Re: [gentoo-user] Is my system (really) using nptl Date: Mon, 15 Oct 2012 00:32:59 +0200 Message-ID: <6778833.iCzrs0J5kD@localhost> User-Agent: KMail/4.9.2 (Linux/3.4.14; KDE/4.9.2; x86_64; ; ) In-Reply-To: References: <50781A2B.3030509@taydin.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Archives-Salt: 666512a4-efac-4823-a616-b35864b5f88d X-Archives-Hash: e2a27952edc78daed87a089dc73c7b50 Am Samstag, 13. Oktober 2012, 19:20:25 schrieb Michael Mol: > On Sat, Oct 13, 2012 at 4:18 PM, Canek Pel=E1ez Vald=E9s =20 wrote: > > On Sat, Oct 13, 2012 at 2:50 PM, Michael Mol wr= ote: > > [snip] > >=20 > >> (Well, I'm not certain that POSIX thinks of threads as parents to = each > >> other.>=20 > > Hence the reason I put "parent" in quotes, and I specified "actuall= y, > > the thread that created it". > >=20 > >> There are *numerous* IPC mechanisms available on Linux. For starte= rs, > >> there are sockets (domain, IPv4, IPv6, et al), named pipes, signal= s, > >> mmap()'d files, messaging, etc. > >=20 > > Yeah, none of them "easy and quickly" to use, or at least not if yo= u > > compare it with shared memory. >=20 > I assume you mean 'shared memory' in the 'many threads to an address > space', not the /dev/shm sense. >=20 > >> When one process writes to the chunk of its address space mapped t= o > >> that file, the other process can immediately see those changes. Al= l > >> 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 fo= r > >> updates. > >=20 > > Yup, certainly neither "easy" nor "quick". >=20 > In C (or C++, or any language capable of directly manipulating mmappe= d > regions), that's about as dead simple as it gets. Nothing else comes > close to that degree of efficiency for that degree of simplicity. >=20 > >> dbus is only a 'little wonder' in that it provides protocol > >> constraints and language bindings, which isn't really relevant whe= n > >> we're talking about same-address-space vs separate-address-space > >> threading models. > >=20 > > 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. >=20 > 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. >=20 > >>> AFAIK, Google Chrome was > >>> the first desktop program in Linux which uses several processes > >>> runnning under the same GUI. > >>=20 > >> Absolutely not. I used to play a game called 'realtimebattle' > >=20 > > OK, I will rephrase it: Google Chrome is the first *relevant* deskt= op > > program in Linux which uses several processes runnning under the sa= me > > GUI. >=20 > 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. >=20 > 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: >=20 > * 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=20 for all those modules to talk to each other. Why they dumbed down to db= us - I=20 don't know. --=20 #163933