harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [vmi] thread library
Date Wed, 31 Jan 2007 10:29:27 GMT
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.

>> > >                    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?

> 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.

Regards,
Tim

Mime
View raw message