From: Andrew Cagney <cagney@redhat.com>
To: Phil Muldoon <pmuldoon@redhat.com>
Cc: frysk@sourceware.org
Subject: Re: vfork thoughts
Date: Wed, 18 Jun 2008 23:12:00 -0000 [thread overview]
Message-ID: <48590D25.90307@redhat.com> (raw)
In-Reply-To: <48565AD5.8050902@redhat.com>
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
>
>
next prev parent reply other threads:[~2008-06-18 13:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-16 13:14 Phil Muldoon
2008-06-18 23:12 ` Andrew Cagney [this message]
2008-06-20 13:45 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48590D25.90307@redhat.com \
--to=cagney@redhat.com \
--cc=frysk@sourceware.org \
--cc=pmuldoon@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).