Hallo!
On Thu, 24 Nov 2011 15:59:55 -, Planet GNU wrote:
> Many articles uniformly claim that using vfork should be
> [avoided][1] and that the only difference between vfork and fork is (or
> used-to-be) [performance][2] and that thus vfork is [obsolte][3]. Here, I
> wanted to document a tech
Programs which depend on the special suspend-the-parent behavior of vfork
were always regarded as buggy...
Thomas
On Fri, Nov 25, 2011 at 7:42 AM, Thomas Schwinge wrote:
> Hallo!
>
> On Thu, 24 Nov 2011 15:59:55 -, Planet GNU
> wrote:
> > Many articles uniformly claim that using vfork shoul
The original BSD man page warned that the behavior should not be relied on.
Thomas
On Nov 25, 2011 4:10 PM, "Christian Grothoff"
wrote:
> On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote:
>
>> Programs which depend on the special suspend-the-parent behavior of
>> vfork were always regarded as
Oh, and in the case you describe there:
The hypervisor at start creates a global variable hypervisor_pid,
initialized from getpid().
The signal handler in the hypervisor then does this:
if getpid() == hypervisor_pid
kill_all_children_and_exit();
else
exit();
In this way, if the child is bet
On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote:
Programs which depend on the special suspend-the-parent behavior of
vfork were always regarded as buggy...
So relying on the well-documented behavior of a system call is a bug?
Did you even read about the scenario I described at
https://gnune
