apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Pools in threads
Date Sun, 15 Jul 2001 18:10:23 GMT
On Sun, Jul 15, 2001 at 07:52:46PM +0200, Sander Striker wrote:
> Can't we pass in a data structure to the thread function which has
> all the required information? The data the user wants to pass in will
> need to be in the data structure aswell ofcourse.

-0.9.  I don't like the idea of marshaling the data to the thread's
worker function.

I'm seeing the proposed marshaling like so:

struct {
 void *data;
 apr_pool_t *pool;
} apr_thread_starter_t;

void * worker_function(void *v)
 apr_thread_starter *ts = v;
 whatever_the_thread_really_wants_t *d = ts->data;

apr_thread_create(blah, blah, blah)
  apr_thread_starter *ts = apr_palloc(...);
  ts->data = the-data-that-user-really-wants-to-pass-in;  
  ts->sms = apr_pool_create(blah, blah, blah);

  thread_create(go call worker_function with ts as the sole argument)


Since I'm seeing the thread SMS be completely separate from the parent
SMS, I'm just not sure why we even want to pass the sms along.  

Unless you can make a case that the thread's SMS needs to know about the
parent SMS.  If so, then we've got major problems in our SMS design.

In order to provide a win against the current pool code in a threaded
MPM, we *need* to have thread-specific SMS that have no locks or
association to anything other than a simple unlocked (from APR's
perspective) malloc/free (aka std) SMS.  -- justin

View raw message