From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5b68877f993232fb23394caf30309e12@plan9.bell-labs.com> From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] Fork: useless and painful? In-Reply-To: <212c59d55eb25badcbc00c9fe4121065@vitanuova.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-jrpdqxmobcqupmhypihhqmtytf" Date: Thu, 10 Jul 2003 12:47:14 -0400 Topicbox-Message-UUID: f376aa94-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-jrpdqxmobcqupmhypihhqmtytf Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit That's why we have libthread with its threadcreate/proccreate/procexec. I've been moving stuff over to windows and just kept the libthread interface. It's amazing how awkward win32 makes all of the same. Every process control call turns into a handful of calls, each with a dozen params. --upas-jrpdqxmobcqupmhypihhqmtytf Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Thu Jul 10 10:59:13 EDT 2003 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Thu Jul 10 10:59:10 EDT 2003 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id 196E319A9E; Thu, 10 Jul 2003 10:57:31 -0400 (EDT) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.6.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 55D2D19BE4; Thu, 10 Jul 2003 10:57:10 -0400 (EDT) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id BAC0C19A9E; Thu, 10 Jul 2003 10:56:30 -0400 (EDT) Received: from rapido.vitanuova.com (unknown [62.254.170.97]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 9768219BE4 for <9fans@cse.psu.edu>; Thu, 10 Jul 2003 10:56:18 -0400 (EDT) Message-ID: <212c59d55eb25badcbc00c9fe4121065@vitanuova.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] Fork: useless and painful? From: rog@vitanuova.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 10 Jul 2003 15:59:34 +0100 X-Spam-Status: No, hits=0.3 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) > I'm hearing the claim that fork is "useless and painful" (from an IBM K42 > guy). > > Maybe it's just me, but I've always liked fork. fork's kinda nice, but can be confusing. plan9 has really moved away from fork for multithreaded programs towards the "spawn" style proccreate. (rfork for other resource attributes is quite different, i think) a day or so ago, i had occasion to write the following code: int mpipe(void) { char buf[BUFSIZE]; int n, p[2]; pipe(p); if(fork() == 0){ if(fork() == 0){ close(p[1]); return p[0]; } close(p[0]); while((n = read(0, buf, sizeof(buf))) > 0) write(p[1], buf, n); exits(nil); } close(p[0]); while((n = read(p[1], buf, sizeof(buf))) > 0) write(1, buf, n); exits(nil); } there's nothing particularly complicated going on and i don't *think* the implementation is particularly obtuse, but i don't find reading that code straightforward. here's a different structure to the same end: int mpipe(void) { int p[2]; pipe(p); spawn copy(0, p[1]); spawn copy(p[1], 1); return p[0]; } void copy(int fd0, int fd1) { char buf[BUFSIZE]; int n; while((n = read(fd0, buf, sizeof(buf))) > 0) write(fd1, buf, n); } ok, i cheated, assuming that C has been given a "spawn" statement similar to Limbo's. nonetheless, i think the structure itself is clearer, and the meaning of the code more transparent - no possibility of accidentally duplicating the *caller* of mpipe... given that forking a process in plan 9, unlike unix, is not synonymous with forking its file descriptors, surely the only real reason to prefer it is that the call fits more nicely into the C syntax; one doesn't have to bypass typechecking in order to pass arguments to a new process. how often does anyone do anything with fork that could not be done at least as easily with spawn? --upas-jrpdqxmobcqupmhypihhqmtytf--