harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [drlvm][classlib] thread library - let there be one!
Date Wed, 20 Sep 2006 12:13:55 GMT
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 <artem.aliev@gmail.com> 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. <geir@pobox.com> 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


Mime
View raw message