Stipe Tolj wrote:
>
> ok, I just commited this:
>
> 2003-06-19 Stipe Tolj <[EMAIL PROTECTED]>
> * gwlib/gwthread.h, gwlib/gwthread-pthread.c: added function
> gwthread_table_slot() to provide the slot integer of threadtable
> the thread is using.
> * gwlib/log.c: fixed Micha
ok, I just commited this:
2003-06-19 Stipe Tolj <[EMAIL PROTECTED]>
* gwlib/gwthread.h, gwlib/gwthread-pthread.c: added function
gwthread_table_slot() to provide the slot integer of threadtable
the thread is using.
* gwlib/log.c: fixed Michael's reported bug for the logging
At 05:54 PM 6/19/03 +0200, Stipe Tolj wrote:
Konstantin Vayner wrote
>
> imho there is no point logging each _thread_ into separate file...
> maybe instead logging thread _types_ into separate files?
> then , mapping can be made on thread name instead of id...
it's more this way:
smsc modules have
Michael Mulcahy schrieb:
>
> > 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
>
>
Andreas Fink schrieb:
>
>
> 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...
ahhh, Andreas *is* right here.
We don't take into account that the threadtable handling does a linear
scan in the threadtable to
Andreas Fink wrote:
>
> 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, the second thread (1034) can not be in the same threadtable slot
as the first one.
The slots are filled sequentially. So at a spe
Alexander Malysh wrote:
>
> oops, that was wrong :(
>
> here is the possible solution:
> static void delete_threadinfo(void)
> {
> struct threadinfo *threadinfo;
>
> threadinfo = getthreadinfo();
> list_destroy(threadinfo->joiners, NULL);
> close(threadinfo->wakefd_recv);
> c
003 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
oops, that was wrong :(
here is the possible solution:
static void delete_threadinfo(void)
{
struct threadinfo *threadinfo;
threadinfo = getthreadinfo();
list_destroy(threadinfo->joiners, NULL);
close(threadinfo->wakefd_recv);
close(threadinfo->wakefd_send);
THREAD(threadi
On Jeudi, juin 19, 2003, at 06:03 Uhr, Stipe Tolj wrote:
Nisan Bloch schrieb:
Hi
We run into this all the time with out SMPP server. Threads are spawned for
new ESME connections and terminated on disconnect. Some of our users
connect and disconnect very regularily and the thread-id often goes o
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 pr
Hi,
Am Donnerstag, 19. Juni 2003 18:36 schrieb Stipe Tolj:
> Michael Mulcahy schrieb:
> > 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 m
> how about having this inside gwthread-pthread.c as function:
>
> /* Return the threadtable sloot this thread is using. */
> long gwthread_table_slot(void)
> {
> return (gwthread_self() % THREADTABLE_SIZE);
> }
>
> and use this call instead of gwthread_self() for the logging
> functions?!
h
Michael Mulcahy schrieb:
>
> 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
> pro
At 05:54 PM 6/19/03 +0200, Stipe Tolj wrote:
Konstantin Vayner wrote
>
> imho there is no point logging each _thread_ into separate file...
> maybe instead logging thread _types_ into separate files?
> then , mapping can be made on thread name instead of id...
it's more this way:
smsc modules have
June 2003 17:04
> To: Nisan Bloch
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Bug in log.c
>
>
> Nisan Bloch schrieb:
> >
> > Hi
> >
> > We run into this all the time with out SMPP server. Threads
> are spawned for
> > new ESME connectio
Nisan Bloch schrieb:
>
> Hi
>
> We run into this all the time with out SMPP server. Threads are spawned for
> new ESME connections and terminated on disconnect. Some of our users
> connect and disconnect very regularily and the thread-id often goes over
> 1024. This however means quite a few chan
a hard limit to reach in normal life - but can still become an issue if
someone is trying to crash the machine...
for example, opening 2000 concurrent connections to the machine from the
outside will pass the 1024 barrier without any problem...
Stipe Tolj wrote:
a) change gwthread code to use t
Konstantin Vayner wrote
>
> imho there is no point logging each _thread_ into separate file...
> maybe instead logging thread _types_ into separate files?
> then , mapping can be made on thread name instead of id...
it's more this way:
smsc modules have IO threads, those get registered via log_t
TCPSocket.new('127.0.0.1', 13001)
t.close
count += 1
end
Hope that helps explain it a bit better,
Warmest Regards,
Michael.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Stipe Tolj
> Sent: 19 June 2003 14:58
&
imho there is no point logging each _thread_ into separate file...
maybe instead logging thread _types_ into separate files?
then , mapping can be made on thread name instead of id...
Stipe Tolj wrote:
ok,
so we have 2 alternative here:
a) change gwthread code to use the freed slot ID number ins
> a) change gwthread code to use the freed slot ID number instead of
> incrementing. So we will never have a thread id above 1024 (which is
> the hard thread limit).
> b) thing how we can map the thread to the exlusive log file
to be honest I'd like to pick a), because b) should be pretty fast
bec
ok,
so we have 2 alternative here:
a) change gwthread code to use the freed slot ID number instead of
incrementing. So we will never have a thread id above 1024 (which is
the hard thread limit).
b) thing how we can map the thread to the exlusive log file
any ideas?!
Stipe
[EMAIL PROTECTED]
---
Michael Mulcahy wrote:
>
> Hi Stipe,
>
> There does not need to be more 1024 concurrent threads to
> reproduce this problem. The problem is associated with
> the internal thread number assigned to each thread. the
> log output displays this number in brackets.
>
> The new logging of threads to a
a bit better,
Warmest Regards,
Michael.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Stipe Tolj
> Sent: 19 June 2003 14:58
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Bug in log.c
>
>
> Hi Michael
Hi Michael,
Michael Mulcahy wrote:
>
> Hi All,
>
> There is a bug in the logging functions debug, info, warning, error and
> panic
> which cause a crash when called from a thread that has a thread id larger
> than 1024, i.e. gwthread_self returns value > 1024
>
> In the log module there is an a
Hi All,
There is a bug in the logging functions debug, info, warning, error and
panic
which cause a crash when called from a thread that has a thread id larger
than 1024, i.e. gwthread_self returns value > 1024
In the log module there is an array for mapping threads to logfiles:
#define THREAD
27 matches
Mail list logo
