> Fair enough. It's just that in order to opt-out of the child-pool creating > process in apr_thread_create, we're going to have to add a parameter
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. > to the call and that means changing programs that currently using it, > like httpd. > > Would it be nicer to just add new parallel apr_smsthread_create > [name is not > important] functions that do this and allow for the opting-out also? I can > provide a patch for this. Hmmm, the thought of a double interface doesn't bring out happy feelings with me I'm afraid. Sander
