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?:)
On 9/25/06, Weldon Washburn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
