harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Angela Lin" <alin.harm...@gmail.com>
Subject Re: [vmi] thread library
Date Fri, 02 Feb 2007 19:49:49 GMT
On 2/2/07, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:

> BTW, what are the particular advantages of having asynchronous signal reporter
> thread being managed by thread library?

The main advantage is that it makes the thread compatible with VM
instrumentation for debugging and profiling.

Do you really feel that it is a better solution to support multiple
thread APIs instead of one?
The 2-layer approach (i.e. hythreadlib for the VM + micro threadlib
for other component) was already discussed for the classlib, along
with the reasons why it is not the best idea.

> Speaking of a asynchronous signal reporter thread, hythread_create() is an
> additional dependency of libhyprt.so on libhythr.so, present only on Linux.

The dependency exists for any POSIX-like platform. Windows has a
signal handling mechanism that doesn't require an additional thread.

> >> > >                     9 hythread_detach
> >> > >                    40 hythread_self
> > These should be included if hythread_attach() is included.
> Agreed.
> Note, that hythread_self() is currently only used as a parameter to
> hythread_tls_set/get, so it has no direct users, and can be eliminated
> together with tls functions.

hythread_self() has value in a generic API. It eliminates the need for
the hythr client to cache its own copy of its hythr handle.

> >> > >                    14 hythread_global
> > In general, this function is used to set/get threadlib-wide settings
> > (like a process-wide global variable). The VM often uses
> > hythread_global() to pass configuration settings to hythr, such as
> > when the command-line arguments are parsed.
> In case threading library is provided by the VM, it becomes somewhat dubious
> to depend on it for process-global variables. I think that assumption
> that hyprt.dll is a single instance library is equally feasible.

It's not intended that you rely on the threadlib for all global variables.

My impression is that one of the reasons for hythread_global() is to
workaround threadlib initialization problems caused by the order that
the threadlib was being loaded with respect to VM initialization and
argument parsing.  If the launcher rework being proposed in the other
discussion can handle threadlib initialization better, then this API
could be deprecated.

One small benefit of hythread_global() is that it can automatically
serialize access to globals.

> The problem with "one big lock" being provided by thread library is that it is
> needed at the port library initialization stage, when the thread library may
> not be present yet.

... which may be better resolved by refactoring the portlib.


View raw message