harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: The state of signal portability
Date Fri, 06 Mar 2009 17:31:16 GMT

> Is there any consensus that the portlib should be rewritten to use the APR?
I don't think this will ever happen.

To my understanding limited APR (without APR-util  and APR-iconv) has
better strategic potential to mature. As for portlib, it has few very
good findings like the type system but lacks the community. An
important thing which can be guessed about the portlib is its design
allows one to plug in runtime an optimized implementation instead of
the open source one, hence this may be a reason why most project
contributors want to base our class library on portlib API rather than
directly on APR.

OS memory allocation routines are designed to tolerate each other. So
the wrappers do. Memory pools are built on the top of a standard
malloc. Though one should learn synchronization and de-allocation
peculiarities of different constructs to use each of them correctly.


On Fri, Mar 6, 2009 at 7:58 PM, Ian Rogers <ian.rogers@manchester.ac.uk> wrote:
> 2009/3/6 Alexei Fedotov <alexei.fedotov@gmail.com>
>> Ian,
>> > fit into the Harmony eco-system correctly
>> I have not caught why APR does not fit into the Harmony eco-system
>> correctly. It really does because all these portability functions are
>> just trivial wrappers for OS calls, and Harmony VM is a living
>> example.
> Thanks for your reply Alexei,
> So I've not done the implementation so it is hard for me to say concretely,
> examples I can see are:
> 1) for virtual memory APR provides mmap whereas Harmony's portlib provides
> reserve/commit, the latter appears to be more general and a better fit for
> Windows
> 2) APR has a notion of memory pools, which are good, however, Harmony's
> portlib would need rewriting to share this view of memory pools
> I think APR could be a good fit but only if I want to rewrite the portlib to
> use it. I think Harmony and APR may also need to be made consistent wrt
> virtual memory manangement. In any case I was hoping to focus my effort on
> the VM and not rewriting portlib, that's why I wanted to use portlib in the
> first place.
> Is there any consensus that the portlib should be rewritten to use the APR?
> If there were an effort underway then this would be a good place for me to
> lend support.
> I feel from your letter that you like portlib - if you are determined,
>> then I suggest restoring signal functionality from M7 in M8. I would
>> not recommend forking at M7. Open sourcers needed to concentrate their
>> efforts, hence the last version is always the preferable one.
> I agree, I will still run against the latest Harmony code.
> Regards,
> Ian
> Thanks.
>> On Fri, Mar 6, 2009 at 6:15 PM, Ian Rogers <ian.rogers@manchester.ac.uk>
>> wrote:
>> > Hi,
>> >
>> > I'm in the process of trying to make a VM run using the Harmony class
>> > libraries and I'm having some trouble with portlib when I need to
>> implement
>> > signals. In the hyport header there are still routines relating to signal
>> > handling, but looking into the portlib code they have no implementation.
>> I
>> > believe all signal handling code from portlib was removed prior to M8.
>> > Looking around for inspiration I believe the situation is:
>> >
>> > 1) IBM VMEs use Harmony's portlib and then implements threads and signal
>> > handling using services available from the host OS, the thread services
>> are
>> > exported back to Harmony via hythr.so
>> >
>> > 2) DRLVM in part uses the Harmony porting layer, in part uses Apache
>> > Portable Runtime (APR) and in part uses services from the host OS
>> >
>> > Using APR is tempting, but as it doesn't underly the Harmony portlib it
>> > seems to lead to a mismatch with APR managing somethings and Harmony
>> others
>> > (ie. who allocates data structures for signal handlers APR using an APR
>> > memory pool or Harmony using its). Of course I could rewrite the portlib
>> > using APR, but this is a lot of work. The reserve/commit virtual memory
>> > routines in portlib are also not reflected in APR.
>> >
>> > What I'd like is for each service I need for the VM to be wrapped up in a
>> > portable way. I'd naively assumed portlib did this, which it does except
>> for
>> > signal handling. I'd like to avoid maintaining thread and signal
>> libraries
>> > for all architecture and OS combinations. Harmony's portlib doesn't
>> contain
>> > a solution for signals, APR does contain a solution but doesn't appear to
>> > fit into the Harmony eco-system correctly. I'm left with mixing Harmony's
>> > thread implementation with bespoke signal handler implementations,
>> perhaps
>> > the cleanest and easiest way for me to get these is from a M7 version of
>> the
>> > portlib.
>> >
>> > Has anybody else found a sensible way to avoid this pain?
>> >
>> > Thanks,
>> > Ian Rogers
>> >
>> --
>> С уважением,
>> Алексей Федотов,
>> http://people.apache.org/~aaf/ <http://people.apache.org/%7Eaaf/>

С уважением,
Алексей Федотов,

View raw message