* vfork thoughts
@ 2008-06-16 13:14 Phil Muldoon
2008-06-18 23:12 ` Andrew Cagney
2008-06-20 13:45 ` Tom Tromey
0 siblings, 2 replies; 3+ messages in thread
From: Phil Muldoon @ 2008-06-16 13:14 UTC (permalink / raw)
To: frysk
I've bee reading about vfork challenges for the past week. Here are my
thoughts.
Mark when he fixed an issue related to breakpoints I think crystallized
the issue with vfork in this thread:
http://article.gmane.org/gmane.comp.monitoring.frysk.general/1072
While at first the issue of breakpoints might seem to be nothing to do
with vfork(), it is very relevant. Literature suggests that the use of
vfork for any purpose other than an immediate prelude to an exec call is
not advisable. However, there could - and probably are - examples of
where this is not the case. Also as detailed in Mark's email this makes
the usage of breakpoints troublesome, as child and parent share memory.
If we model vfork transparently though the fork observer then there is a
danger of the user (be that an actual user, or an api call) assuming
that the it is a true fork and not a vfork. Is it more sensible to model
a completely separate set of observers to model vfork? This way, if
there are breakpoints set in the child (and therefore the parent) we can
uninstall them after the child execs. However this approach burdens the
state machine with additional states that would essentially duplicate
the fork states. Is the replication of code to deal with the vfork
specific issues warranted here?
If anyone has a real life use case for debugging a vfork scenario we
could model, that would help also.
Regards
Phil
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: vfork thoughts
2008-06-16 13:14 vfork thoughts Phil Muldoon
@ 2008-06-18 23:12 ` Andrew Cagney
2008-06-20 13:45 ` Tom Tromey
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2008-06-18 23:12 UTC (permalink / raw)
To: Phil Muldoon; +Cc: frysk
Phil Muldoon wrote:
> I've bee reading about vfork challenges for the past week. Here are my
> thoughts.
>
> Mark when he fixed an issue related to breakpoints I think
> crystallized the issue with vfork in this thread:
>
> http://article.gmane.org/gmane.comp.monitoring.frysk.general/1072
>
> While at first the issue of breakpoints might seem to be nothing to do
> with vfork(), it is very relevant. Literature suggests that the use of
> vfork for any purpose other than an immediate prelude to an exec call
> is not advisable. However, there could - and probably are - examples
> of where this is not the case. Also as detailed in Mark's email this
> makes the usage of breakpoints troublesome, as child and parent share
> memory.
Totally agree.
>
> If we model vfork transparently though the fork observer then there is
> a danger of the user (be that an actual user, or an api call) assuming
> that the it is a true fork and not a vfork. Is it more sensible to
> model a completely separate set of observers to model vfork? This way,
> if there are breakpoints set in the child (and therefore the parent)
> we can uninstall them after the child execs. However this approach
> burdens the state machine with additional states that would
> essentially duplicate the fork states. Is the replication of code to
> deal with the vfork specific issues warranted here?
>
> If anyone has a real life use case for debugging a vfork scenario we
> could model, that would help also.
Perhaps look at the fork/daemon code. It uses a vfork, followed by a
fork, followed by an exec. Stepping through that would be way cool!
>
> Regards
>
> Phil
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: vfork thoughts
2008-06-16 13:14 vfork thoughts Phil Muldoon
2008-06-18 23:12 ` Andrew Cagney
@ 2008-06-20 13:45 ` Tom Tromey
1 sibling, 0 replies; 3+ messages in thread
From: Tom Tromey @ 2008-06-20 13:45 UTC (permalink / raw)
To: Phil Muldoon; +Cc: frysk
Phil> If anyone has a real life use case for debugging a vfork scenario we
Phil> could model, that would help also.
gcc uses vfork when spawning child processes. And, the code that
actually does this does do some work between the vfork and the exec --
it is extremely common to move file descriptors around here. So, if
you want to debug in this region, or just want to debug child
processes created by vfork, gcc works :). There are probably a lot of
other examples like this.
Tom
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-06-18 23:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-16 13:14 vfork thoughts Phil Muldoon
2008-06-18 23:12 ` Andrew Cagney
2008-06-20 13:45 ` Tom Tromey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).