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.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Stipe Tolj
> Sent: 19 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 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 changes to the way the
> log stuff
> > currently works. We may have to use a list instead of an array.
>
> hmmm, list are *slow* compared to a fixed array.
>
> You have to keep in mind that the logging functions are caller
> *really* a lot of times anywhere in the code, so the mapping has to be
> as fast as possible.
>
> Is there any concern in changing gwthread-pthread.c code in cycling
> between 1-1024 for the thread_ids instead of incrementing?!
>
> Stipe
>
> [EMAIL PROTECTED]
> -------------------------------------------------------------------
> Wapme Systems AG
>
> Vogelsanger Weg 80
> 40470 D�sseldorf
>
> Tel: +49-211-74845-0
> Fax: +49-211-74845-299
>
> E-Mail: [EMAIL PROTECTED]
> Internet: http://www.wapme-systems.de
> -------------------------------------------------------------------
> wapme.net - wherever you are
>
