httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: ap_current_thread?
Date Tue, 18 May 1999 16:00:03 GMT
Ryan Bloom <> writes:

> >    ap_thread *ap_current_thread(void)
> I have avoided writing this routine, because I am not sure of the best way
> to do it.  I would rather not have a thread table inside of APR, that is
> what the OS is for.  I need to determine if just calling pthread_self (or
> it's equivalent) is enough, or if it is possible that in the future I
> would need to store my own thread info.

I've been assuming roughly that this is what a thread
create would look like..

  #define MAKE_INSTANCE(p,type) ((type *)ap_palloc(p,sizeof(type)))

  ap_thread_t *ap_thread_create(ap_thread_t *parent, 
                                ap_thread_main_t *f, 
                                void *thunk)
    ap_pool_t *thread_pool = ap_make_sub_pool(parent->pool);
    ap_thread_t *t = MAKE_INSTANCE(thread_pool, ap_thread_t);
    t->user_data = NULL; 
    t->pool = thread_pool;
    t->parent = parent_thread;
    t->interupt_handling = ...
    ... platform specific code ...
    ... push(thread, parent->children)...
    return t;

I.e. that every thread would have it's own private pool
for it's fast working storage, and that the tree of 
threads would reside in the tree of pools.

Thread_pool as shown above is critical to making allocation
lock free in the usual case for majority of thread allocation.

Since the platform specific code, is platform specific, it can
use thread local storage to store the state that implements
current_thread.  So I agree that the thread table is a platform
issue, not necessarily represented in APR.  The thread tree, I
think it deserves to be represented in APR.

 - ben

View raw message