On Sun, Jul 15, 2001 at 06:49:51PM +0200, Luke Kenneth Casson Leighton wrote: > On Sat, Jul 14, 2001 at 12:40:06PM -0700, Aaron Bannert wrote: > > > APR threads, when created, would now take an additional parameter that > > is the mechanism (an sms implementation) by which it should create child > > pools. As it is now, the "pool" that is passed in to apr_thread_create() > > serves as the "parent" pool for the new thread-specific sms. If this > > parameter were null, the apr_thread_create() function would not create > > a sub-pool or register cleanup routines (which satisfies my requirements). > > if at all possible, the behaviour should match as closely as possible > the existing situation, when this parameter is NULL, even if the > current situation has bugs / is not very nice. > > this is mainly so that people do not object to having the behaviour > of existing code disrupted.
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 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. -aaron
