> so what if I have a thread 10 which is a EMI/UCP process and
> suddendly a new process gets added with 1034? we have a new conflict...
No, that what I thought as well, but the gwthread-pthread.c takes
care of that problem.
see gwthread-pthread.c
/* Find a free table entry and claim it. */
first_try = next_threadnumber;
do {
ti->number = next_threadnumber++;
/* Check if we looped all the way around the thread table. */
if (ti->number == first_try + THREADTABLE_SIZE) {
panic(0, "Cannot have more than %d active threads",
THREADTABLE_SIZE);
}
} while (THREAD(ti->number) != NULL);
THREAD(ti->number) = ti;
active_threads++;
where THREAD(t) is:
#define THREAD(t) (threadtable[(t) % THREADTABLE_SIZE])
The thread number is incremented and the mod 1024 position in
array is checked to see if an entry exists. If an entry exists then
the thread number is incremented again.
Just to clarify this in my own mind I wrote a program
essentially the following:
/* create 100 threads that sleep indefinitely */
for (i; i < 100; i++)
gwthread_create(sleepy_thread, &val);
/* create 100 threads that sleep for small bit */
for (i = 0; i < 2000; i++)
{
gwthread_create(sleepy_thread, &val2);
gwthread_sleep(0.1);
}
the output shows how the thread number works:
2003-06-19 18:17:18 [0] DEBUG: Started thread 1021
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:18 [0] DEBUG: Started thread 1022
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1023
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1125
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1126
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1127
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1128
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1129
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1130
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
2003-06-19 18:17:19 [0] DEBUG: Started thread 1131
(C:\dev\wirelesswindow\test\test_threads.c:sleepy_thread)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Andreas Fink
Sent: 19 June 2003 17:55
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Bug in log.c
On Jeudi, juin 19, 2003, at 06:26 Uhr, Michael Mulcahy wrote:
Hi All,
Found a solution that I think should be ok.
In the gwthread-module the table is size 1024.
While the thread number may increase byond it the
id is a modulo of 1024 and so the modulo can be
used in the log.c to prevent the prior mentioned
problem.
suggested fix would be to use following:
if ((e = thread_to[(gwthread_self()%1024)])) {
Have tested this and appears to work.
Sorry for not spotting this earlier.
Kindest Regards,
Michael.
so what if I have a thread 10 which is a EMI/UCP process and suddendly a new
process gets added with 1034?
we have a new conflict...
Andreas Fink
Global Networks Switzerland AG
------------------------------------------------------------------
Tel: +41-61-6666333 Fax: +41-61-6666334 Mobile: +41-79-2457333
Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland
Web: http://www.global-networks.ch/ [EMAIL PROTECTED]
------------------------------------------------------------------
