From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32683 invoked from network); 3 Aug 2021 23:13:13 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2021 23:13:13 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id D80749CAB2; Wed, 4 Aug 2021 09:13:10 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 19D6E9CAA5; Wed, 4 Aug 2021 09:12:41 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="XfXBh2ML"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id D6CB49CAA5; Wed, 4 Aug 2021 09:12:38 +1000 (AEST) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 22BB69CAA4 for ; Wed, 4 Aug 2021 09:12:38 +1000 (AEST) Received: by mail-lj1-f180.google.com with SMTP id a7so435574ljq.11 for ; Tue, 03 Aug 2021 16:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=5Vc+BQ+oLXijkamJ2Ge/iSfgj4yh8FJeSkKvQKtyPpE=; b=XfXBh2ML2s7MdwGF5tCOwmkvAbAB+LfnmsSOIONphjcUlZySzfznHZEYHCVzqFToeR vR6FJnB42DKFnMVrfxyPmxrXuAl/TuHJ5YGnshLPQMTSi3HNc+QkgRh3fmz7WQy+W6CR FttLdfwR1dvW2CXu/pfDVgppoh8dS8ZPnBc94XFvbA7V/zDx3LcGLWS+FZiOrjEslCkn 193QGl8mO4zYCG0oCmovu5igzmBH/WdMuWO+7mkWx4FrQ59zWGyJmHJu+kWNKXceZLik FDwcsWxuSGdzwEVvRp8Sh6rX+Ywb7HAcFzloM886053OM6cl0ocNQzQZd9IFxq/19aSg j2IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=5Vc+BQ+oLXijkamJ2Ge/iSfgj4yh8FJeSkKvQKtyPpE=; b=mFMXUCELyQUMFicC0QtYTAvJHrcK1nzNrMQccR6MZ6tdIBwFb9lYazcZRL4Hv5khHe BGx0K468YoqtVyk1J9aWXj5UfZbqnypfZ5Or3qW6zbLFIsLfPEyddedKRemVSzkeE8RC TsZ7nmNNq6GDjw1jN202OP3t4d3VHJaGxAQQrp7+3s+Odg9aP4OXwU1xjPdg5hPWkAI/ uwk0L50XCT6E5UTlO9F7xeiHMhD36x2abMlnPiqEpxWtXS1i3r4eDEBJw8rPGCvXE5bq +Anzf6kAloNZ7r8SrE15xnvXkUbpdOkw82LySMvY4lA6Bw3vkGObIsvP+W3p+jA8sj8q Bzjg== X-Gm-Message-State: AOAM5301RjhzTQwkUIExosXBTISYI5SNiwZU/ql8apLvgZM2F4z3KgIJ SBZsaZy1mcDeBUS0hPMKmJo60+VbwsDxo/YyGjG9cuKU X-Google-Smtp-Source: ABdhPJwf2ZkzZRY8EmQjW9hccxA8ML1+J5hh660pRFnY31hhptagE6ZanaZ8NOvvl3Rn7VeDh24GdD0ZrSpEFd0I8dI= X-Received: by 2002:a2e:9a53:: with SMTP id k19mr16239094ljj.482.1628032355895; Tue, 03 Aug 2021 16:12:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:a288:0:0:0:0:0 with HTTP; Tue, 3 Aug 2021 16:12:35 -0700 (PDT) In-Reply-To: <202108030719.1737JJRc019869@freefriends.org> References: <202108030719.1737JJRc019869@freefriends.org> From: Andrew Warkentin Date: Tue, 3 Aug 2021 17:12:35 -0600 Message-ID: To: tuhs@tuhs.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [TUHS] Systematic approach to command-line interfaces X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 8/3/21, arnold@skeeve.com wrote: > > I haven't caught up yet in this thread. Apologies if this has been > discussed already. > > The Plan 9 folks blazed this trail over 30 years ago with rfork, where > you specify what bits you wish to duplicate. I don't remember details > anymore, but I think it was pretty elegant. IIRC Around that time Rob Pike > said "Threads are the lack of an idea", meaning, if you think you need > threads, you haven't thought about the problem hard enough. (Apologies > to Rob if I am misremembering and/or misrepresenting.) > I've never really been a fan of the rfork()/clone() model, or at least the Linux implementation of it that requires ugly library-level hacks to share state between threads that the kernel doesn't support sharing. Also, I don't really care for the large number of flags required. Up until now I was just planning on following the traditional threading model of associating most state with processes with only execution state being per-thread in the OS I'm working on, but now I'm thinking I should reduce the state associated with a process to just the PID, PPID, PGID, containing cgroup, command line, and list of threads. All other state would be contained in various types of context objects that are not tied to a particular process or thread (other than being destroyed when no more threads are associated with them). This would include: Filesystem namespace File descriptors Address space Security context (file permission list, UID, GID) Signal handlers Scheduling context Each of these object types would be completely separate from the others, allowing full control over which state is shared and which is private. I'm using seL4 as a microkernel, and it already works like this (it has no real concept of processes, only threads that are each associated with an address space, a capability space, and a scheduling context) so it's a good match for it. exec() would still replace all threads within a process as on traditional Unix, unless the exec is performed within a child process that hasn't yet been started. Sending a signal to an entire process would send it to every signal group within the process (similarly, it would be possible to send a signal to an entire cgroup; basically, processes will really just be a special kind of cgroup in this model).