Path: utzoo!utgpu!watmath!att!tut.cis.ohio-state.edu!purdue!haven!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: ReadKey like Function in C Message-ID: <10734@smoke.BRL.MIL> Date: 14 Aug 89 21:48:20 GMT References: <148@trigon.UUCP> <207600029@s.cs.uiuc.edu> <941@lakesys.UUCP> <2357@auspex.auspex.com> <5672@ficc.uu.net> Reply-To: gwyn@brl.arpa (Doug Gwyn) Followup-To: comp.std.unix Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 26 In article <5672@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Hmmm. Does POSIX specify that fork() is the process-creation mechanism? I >hope not... while the fork()-exec() pair is singularly elegant, it's not >implementable (without a massive number of kludges) in a wide variety of >operating systems: OS/9, VMS, RSX, AmigaOS, and in fact any O/S I can think >of off the top of my head other than UNIX. Yes, IEEE Std 1003.1 requires that fork() be supported. Early in the P1003 deliberations, it was decided not to bend over backwards simply to permit layered implementations; the base model was UNIX. Separate fork() and exec(), along with shared file tables etc., provide the means to do a variety of interesting things, and UNIX-based applications do exploit this. If POSIX had tried to weaken this area, it would not have been following its charter. >While I'm here, what's the sentiment among C standards folks for some sort >of standard co-routine arrangement? It cannot be mandated across all implementations. To me, that rules out using it in my applications. And indeed, just last week I devised an interesting algorithm that needs to switch between two tree traversal pointers; coroutines would have been handy, but as it stands I simply had to devise another way to accomplish the desired algorithm within standard C. Note that this can always be done, although it's not as convenient as having genuine coroutine support built into the language.