Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28018 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 18610 invoked by uid 1010); 13 Feb 2007 23:02:55 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 18595 invoked from network); 13 Feb 2007 23:02:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Feb 2007 23:02:55 -0000 Authentication-Results: pb1.pair.com smtp.mail=kingwez@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=kingwez@gmail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.182.191 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: kingwez@gmail.com X-Host-Fingerprint: 64.233.182.191 nf-out-0910.google.com Linux 2.4/2.6 Received: from [64.233.182.191] ([64.233.182.191:39721] helo=nf-out-0910.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/9B-17694-E9342D54 for ; Tue, 13 Feb 2007 18:02:55 -0500 Received: by nf-out-0910.google.com with SMTP id l35so510989nfa for ; Tue, 13 Feb 2007 15:02:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bE7YhxIBrtZNbf/98iBI5cSLsTqCFhKCGdHPzTkmQUeRVKR6yK70pTbOYrG3g6+2gUKHYpPMvwO2SKin6JWH7ELuxPSKkWmk2LC2VHbdWvHQg7CWpKRdEw6iAjUKdswGxbxltPTHn7HyGOh8RrxkmQkjFrqNxsrYrp60mMKzSCI= Received: by 10.82.136.4 with SMTP id j4mr14218473bud.1171407771194; Tue, 13 Feb 2007 15:02:51 -0800 (PST) Received: by 10.82.167.13 with HTTP; Tue, 13 Feb 2007 15:02:51 -0800 (PST) Message-ID: <4e89b4260702131502l76cfc901lca07aee491dca92c@mail.gmail.com> Date: Tue, 13 Feb 2007 18:02:51 -0500 To: "Nuno Lopes" Cc: PHPdev In-Reply-To: <00c901c74fa5$06674da0$0100a8c0@pc07653> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00c901c74fa5$06674da0$0100a8c0@pc07653> Subject: Re: [PHP-DEV] Fw: #39322 [Com]: proc_terminate(): loosing process resource From: kingwez@gmail.com ("Wez Furlong") Patch looks good to me. --Wez. On 2/13/07, Nuno Lopes wrote: > Anything against this: http://mega.ist.utl.pt/~ncpl/php_proc_terminate.txt ? > If not, I'll apply it by the end of the week with some new tests. > > Nuno > > > ----- Original Message ----- > > ID: 39322 > > Comment by: viraptor+phpbug at gmail dot com > > Reported By: c dot affolter at stepping-stone dot ch > > Status: Open > > Bug Type: Documentation problem > > Operating System: Linux 2.4 > > PHP Version: 5.1.6 > > New Comment: > > > > I'd rather like to see proc_terminate act like documented: > > > > "proc_terminate() allows you terminate the process and continue with > > other tasks. You may poll the process (to see if it has stopped yet) by > > using the proc_get_status() function." > > > > If a known workaround is to send posix_kill, which does... exactly what > > proc_terminate is supposed to do, why not implement proc_terminate as: > > > > stat = proc_get_status(proc); > > if(stat['running']) posix_kill(stat['pid'], sig); > > > > ? > > + update the $proc options as needed. That would be much more useful. > > Additionaly not every signal actually kills process, so resource should > > not be destroyed after SIGTERM. > > Please correct code, not docs. > > > > > > Previous Comments: > > ------------------------------------------------------------------------ > > > > [2006-11-08 14:55:16] tony2001@php.net > > > > Reclassified as docu problem. > > > > ------------------------------------------------------------------------ > > > > [2006-10-31 16:22:53] c dot affolter at stepping-stone dot ch > > > > Description: > > ------------ > > After sending a signal via proc_terminate() to a process, the process > > resource gets closed immediately. > > This means that calling proc_get_status() afterwards, will throw a > > warning about an invalid process resource. > > > > This behaviour is somewhat cumbersomely, since you're unable to check > > if it was your signal which has caused the process to terminate or if > > the process has stopped. > > > > Is this a bug or an undocumented behaviour? > > > > BTW: > > Sending a signal via the shell or through posix_kill(), will retain the > > status for the first proc_get_status() call. > > > > Reproduce code: > > --------------- > > > $descriptors = array( > > 0 => array('pipe', 'r'), > > 1 => array('pipe', 'w'), > > 2 => array('pipe', 'w')); > > > > $pipes = array(); > > > > $process = proc_open('/bin/sleep 120', $descriptors, $pipes); > > > > proc_terminate($process); > > var_dump(proc_get_status($process)); > > > > ?> > > > > > > > > Expected result: > > ---------------- > > array(8) { > > ["command"]=> > > string(14) "/bin/sleep 120" > > ["pid"]=> > > int(23011) > > ["running"]=> > > bool(false) > > ["signaled"]=> > > bool(true) > > ["stopped"]=> > > bool(false) > > ["exitcode"]=> > > int(-1) > > ["termsig"]=> > > int(15) > > ["stopsig"]=> > > int(0) > > } > > > > Actual result: > > -------------- > > Warning: proc_get_status(): 7 is not a valid process resource in ... > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > Edit this bug report at http://bugs.php.net/?id=39322&edit=1 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >