From: Andrew Cagney <firstname.lastname@example.org>
To: Mark Wielaard <email@example.com>
Cc: frysk <firstname.lastname@example.org>
Subject: Re: "int pid" replaced with ProcessIdentifier
Date: Thu, 14 Feb 2008 14:25:00 -0000 [thread overview]
Message-ID: <47B44EF1.email@example.com> (raw)
You're right, but we've also not finished working through these
transformations either. As code gets finished, the hacks you refer to
There's one thing that is probably worth clarifying though. Things
break down as follows:
ProcessIdentifier -> this is a live running host system dependent value.
Like the rest of frysk.sys, beyond frysk.proc.live and test cases, code
should not be using those interfaces. A grep, unfortunately, shows
otherwise. We've lots of work to do.
Proc/Task -> this is frysk's internal representation of a process/task
and what client code manipulate
It's important that, as we push towards having our architecture support
remote targets, we clarify the separation between these two.
Mark Wielaard wrote:
> Hi Andrew,
> On Thu, 2008-02-07 at 10:51 -0500, Andrew Cagney wrote:
>> I've pushed a low-level change so that frysk.sys's process code uses a
>> ProcessIdentifier object instead of "int pid"s; there is one
>> ProcessIdentifier per "pid". The change is slowly working its way
>> through frysk.proc.live; it won't be taken further.
>> The motivation is simple, while "int pid" looks small and efficient; it
>> turns out that the code using it really needed an object (leaking
>> something like <<new Integer(pid)>>) to either log or hash the pid.
>> With a proper object both of these cases can be greatly simplified.
> I looked of some of the changes here and it looks somewhat inefficient,
> and very verbose, because it basically replaces everything that already
> has a pid int with a call to ProcessIdentifierFactory.create(pid). A lot
> of these int pids seems to come from Proc.getPid(), which in turn is a
> wrapper for ProcId.hashCode() where the hashCode() of a ProcId is indeed
> the int representation of the pid of the Proc.
> So why not just use ProcId as process identifier for a Proc since that
> is already bound to a Proc object? Or the other way around and do away
> with ProcId and use ProcessIdentifier instead of ProcId. It seems
> confusing to now have 3 ways to identify a process int pid, ProcId and
> ProcessIdentifier (4 if you also count TaskId since I saw also code like
prev parent reply other threads:[~2008-02-14 14:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-07 15:52 Andrew Cagney
2008-02-14 11:00 ` Mark Wielaard
2008-02-14 14:25 ` Andrew Cagney [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).