Re: libiberty/pex-unix vfork abuse?

["J.C. Pizarro" <jcpiza at gmail dot com>]

On 2007/12/7, Dave Korn <dave.korn@artimi.com> wrote:
> On 07 December 2007 18:09, J.C. Pizarro wrote:
>
> > You're wrong. My suggestions are not based from school and are not useless.
>
>   Now /you're/ wrong: your suggestions *are* useless.  You suggested using
> inter-process communications to try and resolve a potential data-access race
> condition between multiple threads within the *same* process.  This can NOT be
> done by any of "filelocks, RPCs, shared memory with mmap and
> mutexes/semaphores, messages passing through pipes as tunnels, MPI".
>
>  - A filelock cannot be used to prevent a second thread within the same
> process from reading from or writing to the environ[] array (or any other
> variable) or calling setenv/getenv while a first thread temporarily swaps the
> value in it.
>
>  - A remote procedure call cannot stop a second thread in the same process
> from reading the environ[] array (or any other ... (etc).
>
>  - An mmap'd shared memory block cannot stop a second thread  ... (etc).
>
>  - Passing a message through a pipe cannot stop a second thread ... (etc).
>
>  - A mutex/semaphore *could* do this, but only if every call to getenv/setenv
> and every direct access to the environ array were *also* wrapped in mutex lock
> calls.  This is not something you can work around in a library implementation
> of pexecute, it would require every author of every program that uses
> libiberty to modify their entire code.
>
>   The fact that you have suggested all those useless suggestions proves that
> you have not understood what we are discussing, which was how to temporarily
> alter the value of a global variable in one thread of a program without any
> other thread seeing the altered value, when we do not control the other
> threads because we are just a library function, not the application itself.
> The generic solution for this problem, which I mentioned in my original post,
> is a "critical section", which is a stretch of code that locks out the
> scheduler from scheduling any other threads of the process to run during the
> period the lock is held.
>
> > Do you permit me a question for you?
> >
> >    "Are important the suggestions?"
>
>   Their importance is proportional to the product of their relevance
> multiplied by their feasibility.  Your suggestions above were all irrelevant,
> except for the unfeasible one.  0*(anything) == (anything)*0 == 0*0 == 0.
>
>     cheers,
>       DaveK
> --
> Can't think of a witty .sigline today....

and you wrote too at start of this topic:

> "The vfork() function shall be equivalent to fork(), except that the behavior
> is undefined if the process created by vfork() either modifies any data other
> than a variable of type pid_t used to store the return value from vfork(), or
> returns from the function in which vfork() was called, or calls any other
> function before successfully calling _exit() or one of the exec family of
> functions."

Briefly, it's fork-like. It's about processes, not threads.
It's about parent and children processes.
And the another man talked about threads (critical section for threads).

   J.C.Pizarro "the noiser" (theirs freedoms that they want to stop me)