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 83D07138010 for ; Sat, 13 Oct 2012 19:51:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6739421C006; Sat, 13 Oct 2012 19:51:20 +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 3AC3A21C00B for ; Sat, 13 Oct 2012 19:50:09 +0000 (UTC) Received: by mail-bk0-f53.google.com with SMTP id jg15so1819204bkc.40 for ; Sat, 13 Oct 2012 12:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=98XLyFXDPKSBXHEEAqnUiqsImiVWnK6Nw573rVnmEQM=; b=W3y22Sx54rdOEE70/YnbpfqAa/IWPkTK8khr1jFpiSJPms71lsyxHa8Yy67qhrQ13C qWHY9JfaJYllHgW0Dk3PiLPYPDTpLtBkhFWV2lqM7CFOYixPgQxVgz/AYTjctQCrg+jP 2M05Wt2RBl/gWx1XSYNI8HnYYYFwqRDwjlFkyl1f/AerRMZSnfJJZNwLVBH/cvjtCSdI TOODHoHCKU0wbY98DLZxlSoi4UZPM7PIQF5qYgRQX4iKCh4hf2Ioo0lex4gD/rVrz9at bpKkzTHZgeDJrFcYxbQQOapMhkMKtxEjG8BVBNpqWCl5HBY++u7hGvEei1hkaWkH6tK6 G9WQ== 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 Received: by 10.204.9.4 with SMTP id j4mr2144590bkj.22.1350157809263; Sat, 13 Oct 2012 12:50:09 -0700 (PDT) Received: by 10.205.83.197 with HTTP; Sat, 13 Oct 2012 12:50:09 -0700 (PDT) In-Reply-To: References: <50781A2B.3030509@taydin.org> <50794D66.1000305@taydin.org> <2356851.Zlj38iKZWL@energy> Date: Sat, 13 Oct 2012 15:50:09 -0400 Message-ID: Subject: Re: [gentoo-user] Is my system (really) using nptl From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 0191265f-dbc1-453d-befb-0d117fdfbff5 X-Archives-Hash: 7ebdaa3da62eb4e140a716b28b6eb94a On Sat, Oct 13, 2012 at 3:00 PM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: > On Sat, Oct 13, 2012 at 1:40 PM, Mark Knecht wrote= : >> On Sat, Oct 13, 2012 at 11:16 AM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: >>> On Sat, Oct 13, 2012 at 12:10 PM, Mark Knecht wr= ote: >>>> On Sat, Oct 13, 2012 at 9:15 AM, Canek Pel=C3=A1ez Vald=C3=A9s wrote: >>>> >>>>> >>>>> We can only know seeing the code. Timur, this is the little test I >>>>> made which creates 5 threads and runs them for 1 minute. In my case, >>>>> `ps x` shows only 1 PID, care to give it a try? [snip] >> Now, this does make me curious about some things running on my system. >> Two for instance, Google Chrome and akonadi_agent, have LOTS of pids. >> I was assuming those were different threads and were demonstrating >> what the OP was asking about, but now I'm not so sure. How does a >> single program on an nptl system generate all these different pids? > > Because Google Chrome is actually LOTS of programs. I don't know about > akonadi (don't use KDE), but Chrome doesn't use threads; it uses > different process for each tab (and for several plugins, I believe), > and it integrates all those process in a single GUI using come kind of > IPC. > > The idea is that if a tab crashes (bad pulgin, rogue JavaScript, > etc.), it only crashes the tab, not the whole browser. It saves us > from the nightmare that forced us to "killall -9 mozilla" from time to > time some years ago. > > A thread is a "lightweight process"; it has its own call stack, but it > shares the same memory space as its "parent" (actually, the thread > that created it). The advantages are many: since all threads in the > same process share the same memory space, they can easily and quickly > communicate between each other. The tradeoff is that if one thread > crashes, the whole program does (AFAIK, someone please correct me if > I'm wrong). You got the semantics right. (We could quibble on tradeoffs, but that's more a question of style and scenario...) (Well, I'm not certain that POSIX thinks of threads as parents to each other. That would seem silly to me, but that may be because I come to multithreaded programming from Windows, where threads belong to a process, not to each other. Your main thread could terminate, but the process would continue to exist until all threads terminated, or until ExitProcess() or TerminateProcess() were called.) > > A process has its own call stack and its own memory space; and while > it can share file descriptors with its parent (the process where it > was created), including pipes, it cannot easily and quickly > communicate with a process different from its parent (hence little > wonders like dbus, whose job is precisely to provice Inter Process > Communication [IPC] between different processes). 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. One IPC mechanism that's fairly common on both Windows and Linux is for two processes to mmap() a block of memory (could be 4KB, could be 40MB, whatever.) by creating an anonymous file. On Linux, this is usually done in /dev/shm/, IIRC. On Windows, you can use a physical file or one of a few different ways. 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. 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. > > For threads in Linux/Unix you usually use POSIX threads, although > there are alternatives. For processes you use fork; everytime you use > "ls" or "cp" in a terminal, or launch a program using KDE or GNOME, > your shell or desktops forks a new process for it. > > Up until very recently most programs used threads to do several things > at once; some years ago apache started to do a "hybrid" approach, > where it forks or launches threads dependign on the load of the > system, other server programs followed it. Apache has several Multi-Processing-Modules. mpm_worker spawns threads within a common process, and each thread handles a different client. mpm_prefork spawns processes, where each process handles a different client= . I'm not aware of any mpm which flips between 'worker' and 'process'. Which mode the administrator chooses depends on his needs. While mpm_worker would be more efficient, almost everybody uses mpm_prefork (or the similar mpm_itk), because modules like mod_php aren't necessarily safe to run in a multithreaded fashion. (It's not necessarily the module's fault, but rather that some of the language extensions aren't written for it.) > 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', a programming game where you programmed a robot to destroy all the competing robots. Realtimebattle would launch your program (written in whatever language you liked, as long as the kernel could launch it) as its own process and communicate with it via stdin/stdout. --=20 :wq