On Wed, 31 May 2023 15:57:19 -0400, Rick Troth wrote: > ... >Reasonable compromise ... it would seem so. >IBM are such sticklers for the rules. What really *is*fork() and what >does Unix do on systems without virtual memory? > <https://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn.html#tag_16_371_08> RATIONALE The posix_spawn() function and its close relation posix_spawnp() have been introduced to overcome the following perceived difficulties with fork(): the fork() function is difficult or impossible to implement without swapping or dynamic address translation. o Swapping is generally too slow for a realtime environment. o Dynamic address translation is not available everywhere that POSIX might be useful.
(But I think the IBM spawn() is a better design.) <https://man7.org/linux/man-pages/man2/vfork.2.html> If they're gonna implement vfork() they should call it "vfork()", not fork(). > ... This is a real question >given that there is a group implementing Unix for 8-bit systems. (Plus >the history that Unix originally ran on many HW platforms which lacked >the ability.) So what canfork() do in cases like that? That might be a >pattern OpenVM could follow. >CMS doesn't do virtual memory ... and that's a feature. > <https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html#tag_16_156_08> There are two reasons why POSIX programmers call fork(). One reason is to create a new thread of control within the same program (which was originally only possible in POSIX by creating a new process); the other is to create a new process running a different program. In the latter case, the call to fork() is soon followed by a call to one of the exec functions. CMS fork() addresses the second, not the first. >But ... yeah ... if you *know* that some programs will (in the source) >be lazy and just callfork() to spawn a child, and immediately exec(), >sher, makes sense. But more rigorous development would callspawn() instead. >Call me lazy. > They shouldn't call it "fork()" while there are alternatives. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
