harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rogers <ian.rog...@manchester.ac.uk>
Subject Re: The state of signal portability
Date Fri, 06 Mar 2009 16:58:11 GMT
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/>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message