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] <mailto:[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 list
[email protected]
<mailto:[email protected]>
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: [email protected] <mailto:[email protected]>
-------------------------------------------
_______________________________________________
Freeswitch-dev mailing list
[email protected]
<mailto:[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]
<mailto:msn%[email protected]>
GTALK/JABBER/PAYPAL:[email protected]
<mailto:paypal%[email protected]>
IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
FreeSWITCH Developer Conference
sip:[email protected]
<mailto:sip%[email protected]>
iax:[email protected]/888
<http://iax:[email protected]/888>
googletalk:[email protected]
<mailto: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
--
-------------------------------------------
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
--
-------------------------------------------
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
