Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of alexei.fedotov@gmail.com
 designates 74.125.46.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=oNBOJz4mHxbJaseJf8ldPbxhPyB/EtClg6kLWA7IDQlPGgLYaniCUolqqKmUZtRPBO
         qUVzeD/uxKOQkBdHMnj9jPN+PyNwcPH5WsB8bcGneWCut/rodxUlnrw3bptwbbp5biib
         HdGJhDiN8OWrUvoKfkyyUgExuJd2i4uIy/Nsk=
MIME-Version: 1.0
In-Reply-To: <b1e4cffb0903060715x1f9512f8qe3458aa5af7823ed@mail.gmail.com>
References: <b1e4cffb0903060715x1f9512f8qe3458aa5af7823ed@mail.gmail.com>
Date: Fri, 6 Mar 2009 19:27:56 +0300
Message-ID: <c30d70960903060827w5e7e904cg74584bdb13591284@mail.gmail.com>
Subject: Re: The state of signal portability
From: Alexei Fedotov <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable

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> wr=
ote:
> 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 impleme=
nt
> 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 a=
re
> 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 othe=
rs
> (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 librarie=
s
> for all architecture and OS combinations. Harmony's portlib doesn't conta=
in
> 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, perhap=
s
> 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
>


--=20
=F3 =D5=D7=C1=D6=C5=CE=C9=C5=CD,
=E1=CC=C5=CB=D3=C5=CA =E6=C5=C4=CF=D4=CF=D7,
http://people.apache.org/~aaf/