On 10/23/06, Angela Lin <[EMAIL PROTECTED]> wrote:

What is the goal here?

1. If the goal is to create a single thread library that can be used
by multiple VM and classlib implementations, then the unified thread
lib should contain everything needed to support a VM implementation.

2. If the goal is to simply define the interface between the classlib
and the VM, then the 3rd option may be acceptable. This option seems
to imply splitting up functionality that requires deep knowledge of
the threading implementation, which I don't like. Each VM
implementation would need to implement both the VM and classlib sides
of the API.

Is this really the situation?  If Classlib only needs monenter/exit, TLS and
thread_create(), the "deep knowledge" required is probably only
monitorenter/exit which seems like a managable situation.


Regards,
Angela

On 10/19/06, Artem Aliev <[EMAIL PROTECTED]> wrote:
> Angela, all,
>
> I see you point and agree.
> But if we move hythread lib to the VM we will require all VMs fully
support it.
> Is it necessary dependency?
>
> So Here is the third way I see.
> Leave the minimum implementation of hythread in the classlib, with the
> set of functions any VM should provide for classlib.
>   This will simplifies adopting classlib to new VM and allows to have
> solid threading model.
> So any VM could have its own super set of threading functions.
>
> Note: Classlib uses only monitor, TLS, and thread_create() from
hythread.
>
> Thanks
> Artem
>
>
>
>
> On 10/18/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > Artem et al,
> >
> > Sorry for jumping in late here.
> >
> > I maintain the J9VM thread lib.
> >
> > Option 1 worries me because it implies that the classlib could use a
> > different threading model from the VM. This is bad because they both
> > operate on the same threads.
> >
> > For example: Layer (2) of hythread might include internal thread state
> > tracking, which is needed to support inspecting the thread state.
> > Using layer (1) directly would bypass the thread state tracking.
> >
> > Angela
> >

Reply via email to