Re: Bug in log.c

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 IO threads, those get registered via log_to_thread()
>to a specific log-file and inside the smsc module code you don't have
>to change anything in the logging functions, which was my most concern
>about it.


which was what made it so easy to roll into our smpp server.

The problem is that the "thread_id" is used as an index into the logfiles 
array.  The thread id is essentially incremented for each thread created, 
so under certain circumstances this can easily be higher than 1024. Either 
through server apps, or lots of use of the stop/start smsc admin functions etc.

The thread id the logging functions use come from the gwlib thread 
functions that maintain a thread table. Each new thread increments the 
thread id, and the entry into the table is calculated by "threadnumber % 
THREADTABLE_SIZE", The new thread code checks for free slots. This is way 
to slow for logging purposes.

But surely then we could in log_thread_to use the same idea

thread_to[thread_id % THREADTABLE_SIZE] = idx
Given that the thread creation code has allready checked that the slot 
"threadnumber % THREADTABLE_SIZE" is free in the thread table and the 
threadnumber is the thread_id.

Nisan

>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