[Freeswitch-dev] freeswitch development question (memory allocation?) [SOLVED]
Apostolos Pantsiopoulos
regs at kinetix.gr
Fri Jan 30 00:02:14 PST 2009
Hi,
One more clarification please :
In order for my thread to use the session data before the session is
destroyed I am using
my own mutex and condition signal. e.g.
(pseudo code follows) :
thread_function(switch_thread_t *thread, void *ptr){
// the pointer ptr is a struct that contains a pointer to session,the
mutex and condition created in the calling thread
(session dependend stuff)
switch_thread_cond_signal(sth->cond); //sends signal to calling thread
that we stopped using the session so it can exit
(session independent stuff)
}
calling_function(switch_core_session_t *session){
(init stuff)
switch_mutex_init(&thread_params->mutex, SWITCH_MUTEX_NESTED, pool);
switch_thread_cond_create(&thread_params->cond, pool);
(thread creation stuff)
switch_mutex_lock( thread_params->mutex );
switch_thread_cond_wait(thread_params->cond,
thread_params->mutex); // this is were the calling thread waits for a signal
switch_mutex_unlock( thread_params->mutex );
return SWITCH_STATUS_SUCCESS;
}
Is the above correct? Is there another way to create a "wait" state for
the calling thread until the child thread
is done with the session data?
Apostolos Pantsiopoulos wrote:
> Thanks for the explanations (both Anthony and Michael).
> You both clarified the subject quite well.
>
> Anthony Minessale wrote:
>> if your intent is to keep the data around longer than the session in
>> it's own thread, you will want to make a new pool
>> and use that pool to launch the thread. pass the pool into the
>> thread as a member of your thread private data and free
>> the pool before you exit the thread.
>>
>> You cannot bring the session with you into the thread unless you read
>> lock the session first so it will not be destroyed while
>> you are using it in the thread.
>>
>> Be aware keeping the session around in the thread just a wild goose
>> chase from doing it the why it already was doing it.
>> The session thread is already independent and it does not stop any
>> other call from proceeding so you may as well do all the work
>> in your session thread in the state change handler like it already
>> does and just add more strict timeout.
>>
>>
>> On Thu, Jan 29, 2009 at 7:23 AM, Apostolos Pantsiopoulos
>> <regs at kinetix.gr <mailto:regs at kinetix.gr>> wrote:
>>
>> The question is : which pool should I use for each different
>> thing I am trying to accomplish?
>>
>> For instance the code below is part of my mod_radius_cdr
>> experimentation.
>> When I am making use of a pool within a module should I :
>>
>> a) create a new pool?
>> b) make use of an existing one?
>> c) what kind of pool should I use?
>> d) is it really just one pool (accessed through different
>> handlers) and I am making myself look like a fool so far?
>>
>>
>>
>>
>>
>>
>> Michael Jerris wrote:
>>> I am not sure even after re-reading what your question is, could you
>>> try to rephrase?
>>>
>>> Mike
>>>
>>> On Jan 29, 2009, at 8:00 AM, Apostolos Pantsiopoulos wrote:
>>>
>>>
>>>> I found it out by myself!
>>>> (why is it that we always come with the solution right after posting
>>>> to
>>>> the list?)
>>>>
>>>> I inserted :
>>>>
>>>> thread_params = switch_core_session_alloc(session,
>>>> sizeof(*thread_params));
>>>>
>>>> before the pool initialization.
>>>>
>>>> But still, can I get some answers to the questions bellow about
>>>> how to effectively handle memory allocations?
>>>>
>>>>
>>>>
>>>> Apostolos Pantsiopoulos wrote:
>>>>
>>>>> I have the code below :
>>>>>
>>>>> struct radacct_thread_handle {
>>>>> switch_core_session_t *session;
>>>>> switch_mutex_t *mutex;
>>>>> switch_thread_cond_t *cond;
>>>>> };
>>>>>
>>>>> static switch_status_t my_on_routing(switch_core_session_t *session){
>>>>>
>>>>> switch_thread_t *thread;
>>>>> switch_threadattr_t *thd_attr = NULL;
>>>>>
>>>>> switch_memory_pool_t *pool;
>>>>>
>>>>> struct radacct_thread_handle *thread_params = NULL;
>>>>>
>>>>> pool = switch_core_session_get_pool(session);
>>>>>
>>>>> thread_params->session = session;
>>>>>
>>>>> ...
>>>>>
>>>>> }
>>>>>
>>>>> when the program reaches the last line (thread_params->session =
>>>>> session;)
>>>>> I get a core dump. Is this a memory allocation error? Is it because
>>>>> I am
>>>>> making
>>>>> use of the wrong pool? Please enlighten me because I am not an
>>>>> experienced c
>>>>> programmer, and I am struggling to get familiar with the FS API.
>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> Freeswitch-dev mailing list
>>> Freeswitch-dev at lists.freeswitch.org <mailto:Freeswitch-dev at lists.freeswitch.org>
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>>> http://www.freeswitch.org
>>>
>>
>>
>> --
>> -------------------------------------------
>> Apostolos Pantsiopoulos
>> Kinetix Tele.com R & D
>> email: regs at kinetix.gr <mailto:regs at kinetix.gr>
>> -------------------------------------------
>>
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at lists.freeswitch.org
>> <mailto:Freeswitch-dev at lists.freeswitch.org>
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>>
>>
>>
>> --
>> Anthony Minessale II
>>
>> FreeSWITCH http://www.freeswitch.org/
>> ClueCon http://www.cluecon.com/
>>
>> AIM: anthm
>> MSN:anthony_minessale at hotmail.com
>> <mailto:MSN%3Aanthony_minessale at hotmail.com>
>> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
>> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
>> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>>
>> FreeSWITCH Developer Conference
>> sip:888 at conference.freeswitch.org
>> <mailto:sip%3A888 at conference.freeswitch.org>
>> iax:guest at conference.freeswitch.org/888
>> <http://iax:guest@conference.freeswitch.org/888>
>> googletalk:conf+888 at conference.freeswitch.org
>> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
>> pstn:213-799-1400
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Freeswitch-dev mailing list
>> Freeswitch-dev at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
>> http://www.freeswitch.org
>>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
--
-------------------------------------------
Apostolos Pantsiopoulos
Kinetix Tele.com R & D
email: regs at kinetix.gr
-------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090130/1bf94130/attachment-0001.html
More information about the Freeswitch-dev
mailing list