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
