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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8789 invoked from network); 15 Dec 2023 17:51:58 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2023 17:51:58 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 8F8DE43E9A; Sat, 16 Dec 2023 03:51:56 +1000 (AEST) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by minnie.tuhs.org (Postfix) with ESMTPS id 59E8143E99 for ; Sat, 16 Dec 2023 03:51:49 +1000 (AEST) Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-28b09aeca73so685032a91.1 for ; Fri, 15 Dec 2023 09:51:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702662708; x=1703267508; darn=tuhs.org; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=h7gydfyuBLk2cYpWHsKLXtxjieoSv8uhe0Bo0D7+LuM=; b=LkKht41jV/MiYFOFei6Z4IprTBnqgx2VuxTxylBjXzwQCOdtZu4DCV9tcB+RllIa43 CPhBg1HVYnTKq6RDM7iOdfeKRDQNLZUS+8/elO8H5pkemzFxsFsvbAd0IcUO9goY0oid Q2ch0KLjbsK7hPKKaQMij/nr2vVjz4AnMlIT7Xyi7lyrmppF9b1wHrNQ426HklUkpTfo 4Oh0VRodz5a/dy4yDen41ULSkuc+PdRGGRYSaPNos1uMpZPBPuf3bVjmeEJI9wK5jncW MlhozwsQ3GP0RXtdYTCnAhweWPe3ghevAfxoNVmxug3vis5q0aJ/BxujHuj/vCkcItyh +ZmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702662708; x=1703267508; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=h7gydfyuBLk2cYpWHsKLXtxjieoSv8uhe0Bo0D7+LuM=; b=Gna1GJdOyUQpNyOmT492I6ZaI7YKke0McwSXUnJ68c2vqCtdLxfQrfWSpELFTef+FO oKSipyJd6Lo/m1a07N5pRjTiK9g++E1SYVAOuO9mxtP9biIUFtjjFugke7ftXQlIHyt5 u9rmv3dO98PnIkdDsKfTWzpoajk2lVxf4haCkat99P14IVCmSL/gGNtSWC7DTpMzx/oF ckar3CJzLNvyRxlxaTqB+icS8fkiMvVjT/fuz+fb+N4mj50qP+jjHH2xx/K4+LwR8+s0 cke2U6klniIFsnHD234IQ88nXpTwq/Ik14sC0Hv1hvongFgw71uCVFIzO0rAVUeYo4eE L4PA== X-Gm-Message-State: AOJu0YzSVISng3xz9ji4s/1TkxY6raUUsaxdR274k1pGaSczJmxAkZrR Rb22rpk1weJgDV8PaHD+o1pMkoX9YEgtTg96D50V1PL8 X-Google-Smtp-Source: AGHT+IHeAZzsCy09Hl85sLR04HViIhfmQ/thWgxHm6NWf2mK4CU2A3weVZPpLPtPhDQySM+4gs1Gax9Ob2DO5sudfi4= X-Received: by 2002:a17:90a:5148:b0:28b:339b:84f2 with SMTP id k8-20020a17090a514800b0028b339b84f2mr1337092pjm.8.1702662708259; Fri, 15 Dec 2023 09:51:48 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6a10:234f:b0:526:f191:393 with HTTP; Fri, 15 Dec 2023 09:51:47 -0800 (PST) In-Reply-To: <4416CB1B-CDE2-42DA-92F2-33284DB6093F@iitbombay.org> References: <20231214232935.802BB18C08F@mercury.lcs.mit.edu> <4416CB1B-CDE2-42DA-92F2-33284DB6093F@iitbombay.org> From: Paul Winalski Date: Fri, 15 Dec 2023 12:51:47 -0500 Message-ID: To: coff@tuhs.org Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: FDIKKCXADMZJG2STAZTZZAB5E7T45PGZ X-Message-ID-Hash: FDIKKCXADMZJG2STAZTZZAB5E7T45PGZ X-MailFrom: paul.winalski@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: Terminology query - 'system process'? List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: For me, the term "system process" means either: o A conventional, but perhaps privileged user-mode process that performs a system function. An example would be the output side of a spooling system, or an operator communications process. o A process, or at least an address space + execution thread, that runs in privileged mode on the hardware and whose address space is in the resident kernel. Do Unix system processes participate in time-sliced scheduling the way that user processes do? On 12/14/23, Bakul Shah wrote: > > Exactly! If blocking was not required, you can do the work in an > interrupt handler. If blocking is required, you can't just use the > stack of a random process (while in supervisor mode) unless you > are doing some work specifically on its behalf. > >> Interestingly, other early systems don't seem to have thought of this >> structuring technique. > > I suspect IBM operating systems probably did use them. At least TSO > must have. Once you start *accounting* (and charging) for cpu time, > this idea must fall out naturally. You don't want to charge a process > for kernel time used for an unrelated work! The usual programming convention for IBM S/360/370 operating systems (OS/360, OS/VS, TOS and DOS/360, DOS/VS) did not involve use of a stack at all, unless one was writing a routine involving recursive calls, and that was rare. Addressing for both program and data was done using a base register + offset. PL/I is the only IBM HLL I know that explicitly supported recursion. I don't know how they implemented automatic variables assigned to memory in recursive routines. It might have been a linked list rather than a stack. I remember when I first went from the IBM world and started programming VAX/VMS, I thought it was really weird to burn an entire register just for a process stack. > There was a race condition in V7 swapping code. Once a colleague and I > spent two weeks of 16 hour debugging days! I had a race condition in some multithread code I wrote. I couldn't find it the bug. I even resorted to getting machine code listings of the whole program and marking the critical and non-critical sections with green and red markers. I eventually threw all of the code out and rewrite it from scratch. The second version didn't have the race condition. -Paul W.