[Freeswitch-dev] freeswitch development question (memory allocation?) [SOLVED]
Anthony Minessale
anthony.minessale at gmail.com
Fri Jan 30 08:40:30 PST 2009
You cannot detain the session at all or you are defeating the purpose of
doing it in another thread.
I already gave you the complete instructions on how to do it properly so
that's all I have to offer.
If you are fetching the session from the hangup event you also run the risk
for a race where the session may have exited already and you will miss it.
Again, you have the channel_hangup event complete with all the data you
would ever need to do the cdr, just clone the event and stick it into a
queue.
On Fri, Jan 30, 2009 at 2:02 AM, Apostolos Pantsiopoulos <regs at kinetix.gr>wrote:
> 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>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 listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://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
>>
>>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888
> googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://www.freeswitch.org
>
>
>
> --
> -------------------------------------------
> Apostolos Pantsiopoulos
> Kinetix Tele.com R & D
> email: regs at kinetix.gr
> -------------------------------------------
>
> ------------------------------
>
> _______________________________________________
> Freeswitch-dev mailing listFreeswitch-dev at lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-devhttp://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
>
>
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20090130/70915612/attachment.html
More information about the Freeswitch-dev
mailing list