Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 42284 invoked from network); 20 Sep 2006 12:14:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Sep 2006 12:14:14 -0000 Received: (qmail 470 invoked by uid 500); 20 Sep 2006 12:14:12 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 433 invoked by uid 500); 20 Sep 2006 12:14:11 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 422 invoked by uid 99); 20 Sep 2006 12:14:11 -0000 Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org) (140.211.166.84) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Sep 2006 05:14:11 -0700 Authentication-Results: idunn.apache.osuosl.org header.from=t.p.ellison@gmail.com; domainkeys=good X-ASF-Spam-Status: No, hits=0.4 required=5.0 tests=DNS_FROM_RFC_ABUSE,RCVD_BY_IP DomainKey-Status: good X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 Received: from ([64.233.182.187:38263] helo=nf-out-0910.google.com) by idunn.apache.osuosl.org (ecelerity 2.1 r(10620)) with ESMTP id E3/A6-00532-E8031154 for ; Wed, 20 Sep 2006 05:14:07 -0700 Received: by nf-out-0910.google.com with SMTP id x4so533892nfb for ; Wed, 20 Sep 2006 05:14:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=rMou9z6UONjHV3gkQyeCku0VlH1WP9pSuo61X0EPIbqOXCNcFD2XPDz4uwAb9qtJ2FXRWc863UyUSk5OYNTr8p3EP0L1czEiAxNR7hhTlK4R5h6wpTA4KLPLGTRoEJmp0p5O0LyVpNSzHmxSH0/eTbvIJFLf63qdeMKONxG0fNs= Received: by 10.78.128.11 with SMTP id a11mr4373234hud; Wed, 20 Sep 2006 05:14:03 -0700 (PDT) Received: from ?9.20.183.164? ( [195.212.29.67]) by mx.gmail.com with ESMTP id 4sm663794hud.2006.09.20.05.14.02; Wed, 20 Sep 2006 05:14:02 -0700 (PDT) Message-ID: <45113083.2050702@gmail.com> Date: Wed, 20 Sep 2006 13:13:55 +0100 From: Tim Ellison User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [drlvm][classlib] thread library - let there be one! References: <187bb05d0609190757qecefcfaq2cd8302b2b1359b5@mail.gmail.com> <12385bbd0609190935h357fb9fdg504e6b9324ecdebe@mail.gmail.com> In-Reply-To: <12385bbd0609190935h357fb9fdg504e6b9324ecdebe@mail.gmail.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Ivan Volosyuk wrote: > Looks like a matter of relations, how the classlib and VM relates to > each other. > > Either VM and classlib independant, then we need something to be > common base for them - portlib. If VM links with classlib, then no > more need for portlib, just well understood interfaces provided by > classlib's HDK. If classlib links with VM, then it is the VM who > should provide this interfaces :) I'm unclear on your definition of 'links with', but I envisage that the portlib and threadlib become a set of utility functions that are usable and sufficient for both the DRLVM and classlib code. It certainly doesn't make sense to maintain two different versions of what is essentially the same thing. Let's look at the differences in implementation and resolve to reconcile them into a single project-wide version. Regards, Tim > On 9/19/06, Artem Aliev wrote: >> Gier, >> >> The hythread is just most visible example. >> There are also signal handling problem. >> classlib hysig lib setup signal handlers and then drlvm overrides them >> by its owns. >> There are code duplication in classlib hyprt.dll drlvm port.lib: >> classlib/trunk/modules/luni/src/main/native/port >> vm/port/src >> >> These three pair of components contains significant part of the system >> dependent code for both VM and CLASSLIB. >> I think, all this code naturally defines portlib component that could >> be shared between classlib and VMs. >> So, as a first step, we could move all this code in to the one place, >> name portlib >> to have three directories classlib, drlvm, portlib. >> >> As the second step, the pairs of libraries should be merged and the >> classlib and drlvm refactoried to have only 3 lib instead of 6. >> >> The 3rd step is to replace most of the functions with APR ones and >> move the rest of the code to the APR. >> >> Thoughts? >> >> Thanks >> Artem >> >> >> >> >> >> >> On 9/19/06, Geir Magnusson Jr. wrote: >> > All, >> > >> > we need to put this issue to bed, as we're tripping over it, it seems. >> > >> > Any thoughts on how to move forward on this? >> > >> > geir > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org > For additional commands, e-mail: harmony-dev-help@incubator.apache.org > > -- Tim Ellison (t.p.ellison@gmail.com) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org For additional commands, e-mail: harmony-dev-help@incubator.apache.org