ReadKey like Function in C

[Doug Gwyn]

In article <5672 at ficc.uu.net> peter at 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.