> > Why are we so desperate in opting out the child-pool creation?
> > I don't really have problems with a child pool for each thread.
> Actually,
> > it will make the dynamic locking a lot easier to implement if it stays.
>
> I have some use cases that just want a thread. Since no child-pool is
> required in this case, it becomes unnecessary overhead (that is currently
> broken, as the child-pool is only cleaned in apr_thread_exit() but that
> whole thing is screwey).
>
> So if apr threads didn't know anything about child-pools, then they
> would just simply create a thread that called my worker_function().
> I could pass in my opaque data to that worker_function(), and do
> the child-pool creations and destruction right there. I just don't see
> how child-pool creation MUST be in apr_thread_create()
Ah, ok, I'm getting the picture now. Well, for my purposes, the child
pool creation doesn't have to be in apr_thread_create. There doesn't
have to be child pool creation at all. But, I do want the worker fn
to be able to create a child pool from the pool passed into
apr_thread_create. So, we need a way to pass in the data to the
worker fn.
The only thing I need is something like this for the sms locking scheme:
struct thread_data
{
...
apr_sms_t *sms;
void (*worker_fn)(void *data);
void *data;
};
void thread_stub(void *data)
{
apr_sms_t *pms;
apr_os_thread_t thread;
struct thread_data *td = (struct thread_data *)data;
thread = apr_os_thread_current();
pms = td->sms;
apr_sms_thread_register(pms, thread);
td->worker_fn(td->data);
apr_sms_thread_unregister(pms, thread);
}
In apr_thread_create an instance of thread_data is created
and initialized, then instead of running the worker function
in the thread, we launch the stub which in turn calls the
worker.
Possibly we can use the stub for more than only this?
Sander
