Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (idunn.apache.osuosl.org: domain gmail.com designates
 64.233.184.231 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=R7Hi9eBGN13Fl8k7TazpEjKbSodMdl6JjFgMa+HMFcHl3Iz5HnqacPCNghiEW/iqGA6Ja7/j0iPb+8wQ4jrAbVZu+yPi2RMx7U8Sf1I2cua8tJtGKuxpqMweHorMntKW/rDrqCDzb5T4olI1w1flxz+XqnrdjnM2FlSEtzOIPRA=
Message-ID: <4dd1f3f00609261045j10d07489v71747274bde2bba@mail.gmail.com>
Date: Tue, 26 Sep 2006 10:45:32 -0700
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][launcher] I am looking at the interaction between
 {classlib, launcher, drlvm} and {hysock, hysig, hythread}
In-Reply-To: <e66844de0609260434l65cb42f6o14b8f2f638cfabe8@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_12450_7785743.1159292732286"
References: <4dd1f3f00609221128s410191cl35e00df9d6c46e23@mail.gmail.com>
	 <4dd1f3f00609250725k77c29964i418eb506b306b60f@mail.gmail.com>
	 <e66844de0609260434l65cb42f6o14b8f2f638cfabe8@mail.gmail.com>

------=_Part_12450_7785743.1159292732286
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 9/26/06, Leo Li <liyilei1979@gmail.com> wrote:
>
> Hi, Weldon:
>     The usage of the argument of portLibrary is for the function to call
> other functions of the port library if needed. The argument is just a
> virtual function table, as you said, can be any implemenatation of the
> HyPortLibrary struct, not only the HyPortLibrary struct the function
> belongs
> to. Of course, different HyPortLibrary might lead to different behavior of
> the function if the HyPortLibrary is used by it.
>     I think the main purpose of the design is to alter some function of a
> specified HyPortLibrary struct flexibly, especially at runtime: What is
> necessary to do is just to change an entry in HyPortLibrary while the
> altered function can make use of other functions as well as other
> functions
> can use it.
>    Am I all right?:)


Hmmm... Interesting idea you have.  Basically the idea is to rewrite the
virtual function table _before_ any of the functions are used.  This makes
much more sense than the way drlvm currently boots up.  By the way, is there
any documentation that says what you are suggesting?  In other words, was
portlib specifically designed to do what you suggest?

On 9/25/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> >
> > It looks like hysignal.c is using the right monitor enter/exit().  That
> > is,
> > the one
> > from  drlvm/trunk/build/win_ia32_msvc_debug/deploy/jre/bin/hythr.dll
> >
> > However, a bunch of functions in classlib's hysignal.c have an incoming
> > argument of "HyPortLibrary *portlib".  The portlib variable can either
> > point
> > to the original classlib portlib C struct.  Or it can point to PORTLIB
> > which
> > is a C struct with all the entries nulled out (more on this later.)
> >
> > I think the next question to ask is what hysignal.c does with
> > the "HyPortLibrary *portlib" argument.  If anyone knows, please tell us.
> > Otherwise I will keep digging.
> >
> > From stepping through DRLVM bootup, it looks like classlib's portlib is
> > _dropped_  in signalProtectMain().  Then launcher gpProtectedMain calls
> > invocation(PORTLIB,...) where PORTLIB is a nulled out HyPortLibrary C
> > struct.  We need to put comments in the code describing the switch from
> > classlib's portlib to drlvm's nulled out version.
> >
> > On 9/22/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > >
> > > All,
> > > Its not clear at this moment what threading implementation is being
> > > executed when hysignal.c calls hythread_monitor_enter().  If someone
> > > already knows, please tell us.  Otherwise,  I will step through it
> with
> > the
> > > debugger to find out what is going on.
> > >   - Weldon
> > >
> > > --
> > > Weldon Washburn
> > > Intel Middleware Products Division
> > >
> >
> >
> >
> > --
> > Weldon Washburn
> > Intel Middleware Products Division
> >
> >
>
>
> --
> Leo Li
> China Software Development Lab, IBM
>
>


-- 
Weldon Washburn
Intel Middleware Products Division

------=_Part_12450_7785743.1159292732286--