Hallo!
On Sat, 26 Nov 2011 15:53:45 +0100, Christian Grothoff
wrote:
> Thank you Thomas for your suggestion. For our purposes, this is a
> better (certainly more portable) solution that does always work.
Great that Thomas Bushnell could help finding a yet-better solution for
the original prob
Thank you Thomas for your suggestion. For our purposes, this is a
better (certainly more portable) solution that does always work.
Happy hacking,
Christian
On 11/26/2011 02:43 AM, Thomas Bushnell, BSG wrote:
Oh, and in the case you describe there:
The hypervisor at start creates a global va
Samuel Thibault, le Sat 26 Nov 2011 15:14:11 +0100, a écrit :
> Richard Braun, le Sat 26 Nov 2011 15:12:50 +0100, a écrit :
> > On Sat, Nov 26, 2011 at 11:35:29AM +0100, Samuel Thibault wrote:
> > > > (Naturally, the result would be non-portable for systems where
> > > > fork==vfork,
> > > > but t
Richard Braun, le Sat 26 Nov 2011 15:12:50 +0100, a écrit :
> On Sat, Nov 26, 2011 at 11:35:29AM +0100, Samuel Thibault wrote:
> > > (Naturally, the result would be non-portable for systems where
> > > fork==vfork,
> > > but then maybe implementing vfork as fork is the bug? ;-))
> >
> > It's what
On Sat, Nov 26, 2011 at 11:35:29AM +0100, Samuel Thibault wrote:
> > (Naturally, the result would be non-portable for systems where fork==vfork,
> > but then maybe implementing vfork as fork is the bug? ;-))
>
> It's what the norm says.
I think you meant the norm explicitely says vfork can be imp
Christian Grothoff, le Sat 26 Nov 2011 01:09:59 +0100, a écrit :
> 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
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
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
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
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
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
11 matches
Mail list logo
