From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6726 invoked by alias); 14 Feb 2008 14:25:23 -0000 Received: (qmail 6699 invoked by uid 22791); 14 Feb 2008 14:25:21 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Feb 2008 14:25:02 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m1EEOwKP002060; Thu, 14 Feb 2008 09:24:58 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m1EEOvJ0028111; Thu, 14 Feb 2008 09:24:57 -0500 Received: from localhost.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m1EEOuEX009782; Thu, 14 Feb 2008 09:24:56 -0500 Message-ID: <47B44EF1.4000608@redhat.com> Date: Thu, 14 Feb 2008 14:25:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Mark Wielaard CC: frysk Subject: Re: "int pid" replaced with ProcessIdentifier References: <47AB291E.4010004@redhat.com> <1202986787.3365.29.camel@dijkstra.wildebeest.org> In-Reply-To: <1202986787.3365.29.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00070.txt.bz2 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 <>) 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 > >