Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 84332 invoked by uid 500); 17 Jul 2001 16:29:52 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 84316 invoked from network); 17 Jul 2001 16:29:51 -0000 Errors-To: Message-ID: <00d301c10edd$5a137370$93c0b0d0@roweclan.net> From: "William A. Rowe, Jr." To: , "Aaron Bannert" Cc: , References: Subject: Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded Date: Tue, 17 Jul 2001 11:26:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N From: Sent: Tuesday, July 17, 2001 11:13 AM > > I believe that the problem is that the threaded code is creating the > pool, and not advertising it to the thread itself. This is an easy thing > to fix. I do not agree that every APR app that uses threads should have > to create their own thread pools. That is wasted effort by every APR app. > > I would like to see a conclusion to this thread quickly. So, could people > please post their desires quickly, and what they want to see from this. thread-local pools would be a nice improvement, perhaps as an argument to apr_thread_create. They can be flagged such that they avoid locking their own own allocations (of course their 'parent' allocator, malloc, or the parent free-list management, may still need to lock based on platform and so forth). But _unless_ they remain rooted to the top level pool, in apr_process_create they become orphaned, and their cleanups are never executed. That isn't workable. It sounds like (forgive me if I'm stating the obvious) that a pool needs two kinds of parent sms pools. One is the 'heirarchy' for purposes of setup and teardown. The other is the 'allocator', where the blocks will be allocated from. Want to use the conventional 1.3 model? The heirarchial parent is the parent pool, but the allocatation parent is the single top level pool. Want to flip to a malloc, that trusts the clib to 'do the right thing'(sm) with cpu/thread specific free lists? Then we build a very simple malloc/free sms that can be passed as the allocation parent when the pool is created. If I've abused the sms concept here, then correct me, but I don't see any issues remaining beyond semantics and syntax. Bill