[drlvm][threading] Which group to choose for new thread?

[Evgueni Brevnov <ev...@gmail.com>]

Hi community,

I'd like to discuss one particular feature of DRL threading library
with you. TM provides four interface functions that can be used to
create a new native thread or attach existing one to TM. Here they
are:

1. hythread_create(hythread_t *handle, UDATA stacksize, UDATA
priority, UDATA suspend, hythread_entrypoint_t entrypoint, void
*entryarg);
2. hythread_attach (hythread_t *handle);
3. hythread_create_with_group (hythread_t *ret_thread,
hythread_group_t group, UDATA stacksize, UDATA priority, UDATA
suspend, hythread_entrypoint_t func, void *data);
4.hythread_attach_to_group (hythread_t *handle, hythread_group_t group);

As I understand the 1. & 2. are mandatory for any TM implementation.
The 3. & 4. are DRL extenstion. The difference between 1 and 3, 2 and
4 is that the later one takes one additional "group" parameter. This
parameter allows to put a thread in any particular group. Besides that
TM manages one default group. This is special group to track all java
threads for suspension and enumeration purposes. Any thread
created/attached using 1. or 2. appears in the default group as well
as if null is specified as "group" parameter to 3. and 4. This is how
current DRL TM works. Such scheme works fine until used properly. But
I see the following problems/limitations which users can experience.

a) Any NATIVE thread created/attached using 1. or 2. (3. and 4. with
null "group") resides in the java group among all other java threads
running in the VM. These native threads are iterated each time GC (or
something else) suspends and enumerates java threads.

b) If someone creates a new thread using 3. with non null "group" and
later associates that thread with java thread then it will never be
enumerated. In other words we have java thread which is not
stopped/enumerated during GC.

c) Any particular thread can't exist in more than one group
simultaneously. It is possible when threads should be grouped by
different properties.

I'd like to know if you think it SHOULD BE FIXED or it is OK to go with it.

One alternative solution could be to have two internal groups. One for
keeping native threads and another one for java threads. Each thread
exists in one of these groups in any particular time. Instead of 3.
and 4. TM will provide hythread_group_add & hythread_group_remove. It
allows to put one thread into different groups with special property.
Such solution has a little bit more complicated implementation but
seems to be more convenient and consistent.

I appreciate any ideas/comments.

Thanks
Evgueni