Return-Path: 
 <dev-return-24001-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org>
Delivered-To: apmail-harmony-dev-archive@www.apache.org
Received: (qmail 89261 invoked from network); 6 Feb 2007 22:28:53 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 6 Feb 2007 22:28:53 -0000
Received: (qmail 13359 invoked by uid 500); 6 Feb 2007 22:28:58 -0000
Delivered-To: apmail-harmony-dev-archive@harmony.apache.org
Received: (qmail 13337 invoked by uid 500); 6 Feb 2007 22:28:58 -0000
Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@harmony.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@harmony.apache.org>
List-Post: <mailto:dev@harmony.apache.org>
List-Id: <dev.harmony.apache.org>
Reply-To: dev@harmony.apache.org
Delivered-To: mailing list dev@harmony.apache.org
Received: (qmail 13328 invoked by uid 99); 6 Feb 2007 22:28:58 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 14:28:58 -0800
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_HELO_PASS,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 14:28:47 -0800
Received: from [192.168.1.104] (unknown [67.86.14.213])
	(using TLSv1 with cipher AES128-SHA (128/128 bits))
	(No client certificate requested)
	by smtp.mxes.net (Postfix) with ESMTP id 39B7651943
	for <dev@harmony.apache.org>; Tue,  6 Feb 2007 17:28:18 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <45C8FF43.2020208@gmail.com>
References: <45B78F90.6070605@gmail.com>
 <45BFC083.8090506@gmail.com>	 <9247407c0701301433p3b726a4n76c68771fa2bd339@mail.gmail.com>
	 <45C069AD.6050409@gmail.com>
	 <9247407c0701310654t4bc3806cla9fcb7de79bd22cf@mail.gmail.com>
	 <epqepo$blk$1@sea.gmane.org>
	 <9247407c0702020725v234bed0ewf10a0190a4d03591@mail.gmail.com>
	 <5CB7CD54-027E-4544-95A3-4B1D38A17FEB@pobox.com>
	 <9247407c0702051448h7112702ei5f83bd614cfb4a6d@mail.gmail.com>
	 <79F4A44E-1199-46F6-BC36-9A7156A53EA3@pobox.com>
 <9247407c0702060628w46b6707fr5d053c6bfbbb3534@mail.gmail.com>
 <45C8B839.4040802@gmail.com> <2A20063D-DCC8-46E8-AC12-2BBE2ABDAF57@pobox.com>
 <45C8FF43.2020208@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <14671E96-D3E1-444C-8AF8-BF85D8408C6D@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [vmi] thread library
Date: Tue, 6 Feb 2007 17:28:11 -0500
To: dev@harmony.apache.org
X-Mailer: Apple Mail (2.752.3)
X-Virus-Checked: Checked by ClamAV on apache.org


On Feb 6, 2007, at 5:20 PM, Tim Ellison wrote:

> Geir Magnusson Jr. wrote:
>> On Feb 6, 2007, at 12:17 PM, Tim Ellison wrote:
>>
>>> Ronald Servant wrote:
>>>> On 2/5/07, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>>>> And why did you decide this was better than #1?
>>>>
>>>> I didn't.  This could be considered step 1 towards doing #1.
>>>> Producing this patch was much quicker than trying to cease all  
>>>> use of
>>>> the port lib in the launcher.
>>>>
>>>> Having said that, I'm not convinced that #1 is the real answer  
>>>> either.
>>>>
>>> <snip>
>>>
>>> This is a good step forward.  It will relieve our immediate pain of
>>> colliding classlib/drlvm/VME threadlibs.  We can then take a  
>>> breather
>>> and think again about how to bootstrap the portlib for use by the
>>> launcher, but the overhead of this solution is ok for now.
>>
>> This isn't about it not being a good step forward, but rather why not
>> examine the other solution. I always think modifying paths is a hack,
>> compared to deliberately loading the library, for example
>
> The first option was to avoid the port library dependency in the
> launcher code, that seems to be what Ron is proposing by  
> duplicating the
> required functions -- i.e. I think he is doing more of #1 than #2 <g>

Both #1 and #2 avoided the dep as far as figuring out where the lib  
was located, but I thought #1 then used it after it found it.  That  
seems cleaner, I guess.  I'm going to look at the patch and see how  
hard the alternative is.

>
> Whatever the number, it is IMO a reasonable solution to the main  
> problem
> of refactoring the access to the threadlib.  We can then refine the  
> way
> the launcher picks up the library if necessary.
>
> Tim