[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freediameter-help
Subject:    [Help] Thread Contexts
From:       zackhasit () gmail ! com (zack Hasit)
Date:       2013-01-29 12:48:29
Message-ID: CAD0_ocHw=dyJAHgxQtBhmCemTsTiTGYtqqo3TFHnf7m+Yt4Ngg () mail ! gmail ! com
[Download RAW message or body]

Hi, I'll probably have to go with TLS then but before that wanted to make
certain if FD has anything built in already to support passing different
structures per request thread. :)
Thanks


On Tue, Jan 29, 2013 at 7:36 AM, Sebastien Decugis <
sdecugis at freediameter.net> wrote:

> Hi Zack,
>
> Why not using thread local storage here? Also if you have to access the
> data only for a short time, a lock is not that bad :)
>
> Apart from this you could allocate an array of your data and each thread
> uses a different area, but then you need a way for your thread to know
> which thread it is and which area it should access. This is not much
> better...
>
> Sebastien
>
>
>
>
> Le 2013/01/28 22:35, zack Hasit a ?crit :
>
>  Hi Sebastian,
>>
>> I am trying to keep some state in each of the threads that call the
>> call-back function. To give an example, if you see the test_app, there is a
>> separate thread that writes/maintains stats. However if say I need to move
>> that functionality into each thread (such that each thread can do it on its
>> own) then I need to have to maintain the statistics in each thread until it
>> gets flushed.
>>
>> The call back functions provide void *opaque but that memory is shared by
>> all threads ? So I cannot use that without locks.
>>
>> I can also use Thread Level Storage but wanted to avoid it unless really
>> needed.
>>
>> Is there another mechanism to maintain a stateful/static variable which
>> does not make me use locks ? Since stats are per thread I don't really want
>> to have locks at all if I can avoid.
>>
>> Thanks
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freediameter.net/pipermail/help/attachments/20130129/fd5ef260/attachment.html>

[prev in list] [next in list] [prev in thread] [next in thread]