On 1/31/07, Tim Ellison <[EMAIL PROTECTED]> wrote:
Angela Lin wrote:
>> > > 45 hythread_tls_alloc
>> > > 48 hythread_tls_get
>> > > 49 hythread_tls_set
>> > > 47 hythread_tls_free
> As long as you don't share TLS data between the VM and the portlib, it
> doesn't matter whether the portlib uses hythr's TLS API.
Ron implies that there is data shared between the two. Perhaps we
provide for the opportunity to do so by providing these functions in the
threadlib API, even if there is no such sharing taking place today.
My comments were focused on the portlib, not the classlib, and so I
didn't look at the classlib usage closely. I've grepped our codebase
and I don't see the classlib directly using this API.
Ron's comments, regarding this and MACRO_SELF()/hythread_self(),
pertain more appropriately to the problems with loading 2 distinct
thread libraries where only one is expected. i.e. You end up with two
copies of internal threadlib state that aren't synchronized which each
other.
>> > > 20 hythread_monitor_destroy
>> > > 28 hythread_monitor_init_with_name
>> > > 21 hythread_monitor_enter
>> > > 23 hythread_monitor_exit
>> > > 2B hythread_monitor_notify_all
>> > > 32 hythread_monitor_wait
> I encourage you to continue to use these hythr functions for
> consistency of behaviour and compatibility with VM instrumentation, as
> discussed previously.
Yep, and one again I think it would be reasonable to provide a reference
implementation / utility library that has the thin wrappers to the OS
function for VMs that are happy to just pass through.
>> > > 4 hythread_attach
> This is mandatory if you use hythr from any non-hythr-created thread,
> such as the main thread.
>
>> > > 9 hythread_detach
>> > > 40 hythread_self
> These should be included if hythread_attach() is included.
All of attach, detach, and self would be required to be implemented by
the VM.
>> > > 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.
Do we only need this capability for the threadlib, how about the entire
portlib?
I consider this nice to have, but not crucial.
There's a more generic problem of how (and when!) command line
arguments should be passed to the thread library. hythread_global()
addresses the how, but not the when.
> Specifically re: the "one big lock"
> (hythread_global("global_monitor")), the big lock is used to enforce
> process-wide serialization, which is useful for stuff like
> initialization and shutdown in a multiple-vm-per-process environment.
> I would be very careful about changing this.
If there is some contract around honouring this monitor then it needs to
be described.
Use the global monitor as a last resort to enforce process-wide
serialization, particularly to protect resources that may be accessed
by multiple VMs.
POSIX-style signal handlers are a process-wide resource, which is why
the port library holds the global monitor while installing them.
Angela
