From: Phil Muldoon <pmuldoon@redhat.com>
To: frysk@sourceware.org
Subject: vfork thoughts
Date: Mon, 16 Jun 2008 13:14:00 -0000 [thread overview]
Message-ID: <48565AD5.8050902@redhat.com> (raw)
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
next reply other threads:[~2008-06-16 12:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-16 13:14 Phil Muldoon [this message]
2008-06-18 23:12 ` Andrew Cagney
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=48565AD5.8050902@redhat.com \
--to=pmuldoon@redhat.com \
--cc=frysk@sourceware.org \
/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).