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 list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

Reply via email to