public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@redhat.com>
To: Mark Wielaard <mark@klomp.org>
Cc: frysk <frysk@sourceware.org>
Subject: Re: "int pid" replaced with ProcessIdentifier
Date: Thu, 14 Feb 2008 14:25:00 -0000	[thread overview]
Message-ID: <47B44EF1.4000608@redhat.com> (raw)
In-Reply-To: <1202986787.3365.29.camel@dijkstra.wildebeest.org>

Mark,

You're right, but we've also not finished working through these 
transformations either.  As code gets finished, the hacks you refer to 
will disappear.

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.

Andrew


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
> ProcessIdentifierFactory.create(this.process.getMainTask().getTid())).
>
> Cheers,
>
> Mark
>
>   

      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]

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=47B44EF1.4000608@redhat.com \
    --to=cagney@redhat.com \
    --cc=frysk@sourceware.org \
    --cc=mark@klomp.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).