Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:50838 Return-Path: <128bitencrypted@googlemail.com> Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19868 invoked from network); 3 Dec 2010 10:17:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Dec 2010 10:17:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=128bitencrypted@googlemail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=128bitencrypted@googlemail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.83.170 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: 128bitencrypted@googlemail.com X-Host-Fingerprint: 74.125.83.170 mail-pv0-f170.google.com Received: from [74.125.83.170] ([74.125.83.170:62783] helo=mail-pv0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1E/19-49671-8A3C8FC4 for ; Fri, 03 Dec 2010 05:17:12 -0500 Received: by pvf33 with SMTP id 33so1744339pvf.29 for ; Fri, 03 Dec 2010 02:17:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=EjTK4JDSvoqWd/6LoJEhBGvYRc2rfYCx0/phK9pO8Ps=; b=JBbi8KZYwXpDjsKWFLRRjLG8abq1BKr3og7jAQqtRibkR28We8GQClzyXNONi11gHP ic2u6yjj9OAJjX/YZKtQaV+NAeUeS85cmIho3DASKkVdmpnykpoGnWbrPAsbFFJ1tr58 ulK7z+1yz9Knz3dHrswHP3So1Ra/JeQzokCiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xPNlyNtA1OCSFlLKDPFaGD5xQmVHBS3wvl4WKqqTtjEL49rvZ1e3ucEI6UYZMJvbEQ 5AQ/BQnPgrg10YvyyS4oaeInPf4Z6SJM4iRABSG3hTmBXU3iVuJ0/o+gsoc84H0/3xPJ vA3ERdueURBzSxiclunEeWDDw8M7nGrTIm2Zs= MIME-Version: 1.0 Received: by 10.142.97.16 with SMTP id u16mr1633504wfb.185.1291371429085; Fri, 03 Dec 2010 02:17:09 -0800 (PST) Received: by 10.142.215.14 with HTTP; Fri, 3 Dec 2010 02:17:09 -0800 (PST) Date: Fri, 3 Dec 2010 11:17:09 +0100 Message-ID: To: internals@lists.php.net Content-Type: multipart/alternative; boundary=001636e1fc884dc39804967ed778 Subject: ts_free_thread() frees only temporary in multiple parallel threads From: 128bitencrypted@googlemail.com (Gary Zipfel) --001636e1fc884dc39804967ed778 Content-Type: text/plain; charset=ISO-8859-1 I created my own php sapi 1 year ago and it was only single threaded. Now I tried to make it multi-threaded by using TSRM. I got 1 thread starting up and shutting down the TSRM and my module and many other threads executing requests. You can take a look at this abstract example here: DWORD WINAPI test_thread(void*) { TSRMLS_FETCH() // a lot of memory is allocated here // execute the request (just core functions written here) php_request_startup(TSRMLS_C); php_execute_script(fh, TSRMLS_C); php_request_shutdown(TSRMLS_C); ts_free_thread(); // I tried to free the memory allocated through TSRMLS_FETCH() here } int main() { tsrm_startup(1, 1, 0, NULL); sapi_startup(&my_php_sapi); php_module_startup(&my_php_sapi, NULL, 0); sapi_activate(TSRMLS_C); // start 25 threads running "test_thread()" here // call module/sapi shutdown functions tsrm_shutdown(); // all memory gets freed here } The request threads work fine but I noticed that all the copies allocated through TSRMLS_FETCH() last in the memory until tsrm_shutdown() gets executed. So I browsed the web and found that ts_free_thread() should solve it. But now here's the problem: When I'm executing only 1 request thread at a time, everything works fine and ts_free_thread() frees all resources. But when I run multiple threads at the same time the memory gets up and down until all threads finished. But after all threads exited the memory grows up enormous. This is what happens: - start 25 threads -- memory: ~25.000 k - threads finish one by one -- memory: ~25.000 k --> ~4.000 k - all threads finished -- memory: ~40.000 k I was using php 5.2.9 and now tried the same with the latest stable 5.3.3 release but the problem still resists. I found out that the timeout thread seems to reallocate my destroyed resources because it occours short after the thread finishes and gets destroyed. I'm currently not really sure if this is a bug or if I'm doing something wrong?! --001636e1fc884dc39804967ed778--