Re: lynx-dev Uniform treatment of fork() and beginthread() calls in ly

[vtailor]

>     * From: address@hidden
>     * Date: Thu, 25 May 2000 15:10:24 -0400
>>I have posted elsewhere on Usenet that there is a simple procedure for
>>transforming programs like lynx that use fork() calls to programs that
>>use setjmp/longjmp and beginthread().  The basic idea is to setjmp at
>>the fork() point and change the end of the child thread to a call on
>>beginthread followed by a longjmp to the parent thread.
>>
>>It seems to me that the lynx code that has calls on fork() could be
>>streamlined, and all the alternative code version #ifdefs greatly
>>reduced in number if it were rewritten so that both the fork() and the
>>beginthread() versions are set up identically, with setjmp() where the
>>fork() call was originally, and either beginthread() or a fictitious,
>>but similar, beginfork() function at the *bottom* of the child thread,
>>followed by the longjmp to the parent thread.
>>
>>On systems that don't support fork() or beginthread(), it might just be
>>possible to use spawn calls followed by longjmp to the parent thread to
>>call support programs that replace the child functions, depending on
>>just what problems arise in getting things like socket addresses back
>>to the calling process.
>>
>Herewith the thread of the post on comp.programming.threads:
>
>On Tue, 23 May 2000 09:35:12 -0400, John Hickin
> <address@hidden> wrote:
>>"Victor Schneider, Ph. D." wrote:
>>>
>>> I haven't been reading the professional journals for some time, but
>>> somewhere there has to be a theorem proving that fork() under Linux
>>> can be simulated effectively by a combination of setjmp() in place
>>> of fork(), with the child process executing first, followed by longjmp()
>>> at the end of the fork() child process.
>>
>>In single-threaded code this might be OK. In multi-threaded code you
>>will have troubles as setjmp() is unsafe.
>
>I know all about setjmp() being unsafe, but the examples that I have
>scrutinized, such as the bash shell and the linux code, don't fall into
>this category.  I think you can come up with examples that show you
>can't make this work if setjmp or fork is inside a function that doesn't
>call the child thread directly, such as the forkshell() function of ash,
>but otherwise, it most certainly will work.  All you need to do is to
>move the fork() point into the function that descends directly into
>the child thread.
>
Actually, I lied about setjmp/longjmp.  All you need is the following,
where fork() has been moved up the number of levels necessary to bring
it into the function where the child process is called.  The idea is
not to spawn() or beginthread() until the very last moment of the
child process, which then begins the parent process.  Maybe you can
conjure up degenerate situations where this strategy fails, but they
don't exist in programs like ash, bash and lynx, or any other application
programs that make any sense:

/* In place of fork(): */
        pid = childprocess(parameters, ...);
/* Instead of childprocess() exiting at the end, a call of some kind */
/* is spawned or threaded, and any resulting error messages are */
/* printed, followed by a return statement up the chain of command: */
        parentprocess(pid, parameters, ...);
/* Wherein the parentprocess does some kind of a wait loop on the */
/* child process, does semaphore signals, whatever. */
        /* Miscellaneous bookkeeping. */
        return;
}

Note that, in portable programs, beginfork() calls can also be moved
down to the very last moment in child processes to provide the #ifdef
"portable" alternative to the beginthread() calls.

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden