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 <[email protected]>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 > <[email protected]>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 >> [email protected]http://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: [email protected] >> ------------------------------------------- >> >> >> _______________________________________________ >> Freeswitch-dev mailing list >> [email protected] >> 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:[email protected] <msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] <sip%[email protected]> > iax:[email protected]/888 > googletalk:[email protected]<googletalk%3aconf%[email protected]> > pstn:213-799-1400 > > ------------------------------ > > _______________________________________________ > Freeswitch-dev mailing > [email protected]http://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: [email protected] > ------------------------------------------- > > ------------------------------ > > _______________________________________________ > Freeswitch-dev mailing > [email protected]http://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: [email protected] > ------------------------------------------- > > > _______________________________________________ > Freeswitch-dev mailing list > [email protected] > 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:[email protected] <msn%[email protected]> GTALK/JABBER/PAYPAL:[email protected]<paypal%[email protected]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[email protected] <sip%[email protected]> iax:[email protected]/888 googletalk:[email protected]<googletalk%3aconf%[email protected]> pstn:213-799-1400
_______________________________________________ Freeswitch-dev mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
