From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200007181434.KAA00924@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Why rio instead of 8 1/2 From: "rob pike" Date: Tue, 18 Jul 2000 10:34:03 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-boksxlzmvceyogeerziahtendh" Topicbox-Message-UUID: e1dd86a2-eac8-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-boksxlzmvceyogeerziahtendh Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 1) The processes are running in the same, shared memory created by rfork(RFMEM). 2) The wctl named pipe makes it easy for programs like /bin/window to find the window system even if they are not in its name space. this is an issue for plumber commands. 3) This topic is discussed in the Acme paper. There is a data type called XFid that is used to manage a pool of threads in the main proc to handle requests on behalf of clients of the file system process. The advantage of this design is that anything that needs to access global data can do much less interlocking if it's a thread in the main proc rather than a separate proc. Threads are coroutines that schedule cleanly; procs are true process scheduled at arbitrary points by the operating system. -rob --upas-boksxlzmvceyogeerziahtendh Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Jul 18 01:10:43 EDT 2000 Received: from cse.psu.edu ([130.203.3.50]) by plan9; Tue Jul 18 01:10:42 EDT 2000 Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id AAA17048; Tue, 18 Jul 2000 00:55:56 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Tue, 18 Jul 2000 00:55:38 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id AAA17005 for 9fans-outgoing; Tue, 18 Jul 2000 00:55:34 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from trachyte.chigaku6.co.jp (granite.cias.osakafu-u.ac.jp [157.16.91.52]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id AAA17001 for <9fans@cse.psu.edu>; Tue, 18 Jul 2000 00:55:28 -0400 (EDT) From: okamoto@granite.cias.osakafu-u.ac.jp Message-Id: <200007180455.AAA17001@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Why rio instead of 8 1/2 Date: Tue, 18 Jul 2000 13:56:02 0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-lwtvadrrpgkwqocyjzxjhnsowv" Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk This is a multi-part message in MIME format. --upas-lwtvadrrpgkwqocyjzxjhnsowv Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thanks Rob! Now, I got that it shows the state of channel communication. I got another difficulty to understand how the rio works. Of course it comes from my personal inablility to read the sources, however, I suppose it's not so easy to some of Plan 9 users like me, either. 1) all the seven procs have the same memory size, and grows coincidently alltogether. Why? Only the process of threadmain() can grow, can't it? 2) proc wctlproc does only check "New" command, and writectl() is called from xfidwrite() which is checked by normal filsyproc(). So, why /srv/riowctl.$user.$pid is posted? The "New" command can also be checked from the normal filsysproc(), can't it? 3) filsysproc() calls file operation functions in fsys.c, and many of those functions call coresponding xfidxxx functions through channel x->c. Why these two processes are separated? Or what is the merrit to use channel for this purpose, but not just function call by pointer alone? Kenji --upas-lwtvadrrpgkwqocyjzxjhnsowv Content-Type: message/rfc822 Content-Disposition: inline Received: from elmo.cias.osakafu-u.ac.jp (elmo.cias.osakafu-u.ac.jp [157.16.103.2]) by granite.cias.osakafu-u.ac.jp (8.9.3/8.9.3) with ESMTP id IAA19626 for ; Fri, 14 Jul 2000 08:37:06 +0900 Received: from cse.psu.edu (majordom@claven.cse.psu.edu [130.203.3.50]) by elmo.cias.osakafu-u.ac.jp (8.9.3/3.7W-00051217) with ESMTP id IAA28075; Fri, 14 Jul 2000 08:37:21 +0900 (JST) Received: from localhost (majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) with SMTP id TAA14846; Thu, 13 Jul 2000 19:35:34 -0400 (EDT) Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 13 Jul 2000 19:35:03 -0400 Received: (from majordom@localhost) by cse.psu.edu (8.8.8/8.8.8) id TAA14786 for 9fans-outgoing; Thu, 13 Jul 2000 19:34:58 -0400 (EDT) X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f Received: from plan9.cs.bell-labs.com (plan9.bell-labs.com [204.178.31.2]) by cse.psu.edu (8.8.8/8.8.8) with SMTP id TAA14780 for <9fans@cse.psu.edu>; Thu, 13 Jul 2000 19:34:53 -0400 (EDT) Message-Id: <200007132334.TAA14780@cse.psu.edu> To: 9fans@cse.psu.edu Subject: Re: [9fans] Why rio instead of 8 1/2 From: "rob pike" Date: Thu, 13 Jul 2000 19:34:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Then, No. (2) and (5) procs are marked as rendez. I looked into sources, however, I failed to understand where the No.2 and 5 processes are called rendezvous. I know I'm missing something... They aren't called rendezvous, they're in the rendezvous state. That field of the ps output is the state of the process, typically a system call name (such as Wait, Read, etc.) or a process state (Fault, Rendez, etc.) -rob --upas-lwtvadrrpgkwqocyjzxjhnsowv-- --upas-boksxlzmvceyogeerziahtendh--