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 16:27:56 GMT
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.

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.

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/

Mime
View raw message