Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:28019 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35582 invoked by uid 1010); 13 Feb 2007 23:19:47 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 35567 invoked from network); 13 Feb 2007 23:19:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Feb 2007 23:19:47 -0000 Authentication-Results: pb1.pair.com header.from=nlopess@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=nlopess@php.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain php.net from 212.55.154.23 cause and error) X-PHP-List-Original-Sender: nlopess@php.net X-Host-Fingerprint: 212.55.154.23 relay3.ptmail.sapo.pt Linux 2.4/2.6 Received: from [212.55.154.23] ([212.55.154.23:48618] helo=sapo.pt) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6E/20-31055-A8742D54 for ; Tue, 13 Feb 2007 18:19:39 -0500 Received: (qmail 19567 invoked from network); 13 Feb 2007 23:19:35 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.208) by relay3 with SMTP; 13 Feb 2007 23:19:35 -0000 Received: (qmail 19314 invoked from network); 13 Feb 2007 23:19:35 -0000 X-AntiVirus: PTMail-AV 0.3-0.88.6 X-Virus-Status: Clean (0.06112 seconds) Received: from unknown (HELO pc07653) (nunoplopes@sapo.pt@[82.155.77.81]) (envelope-sender ) by mta13 (qmail-ldap-1.03) with SMTP for ; 13 Feb 2007 23:19:35 -0000 Message-ID: <006701c74fc5$6b9643f0$0100a8c0@pc07653> To: "Wez Furlong" Cc: "PHPdev" References: <00c901c74fa5$06674da0$0100a8c0@pc07653> <4e89b4260702131502l76cfc901lca07aee491dca92c@mail.gmail.com> Date: Tue, 13 Feb 2007 23:19:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Subject: Re: [PHP-DEV] Fw: #39322 [Com]: proc_terminate(): loosing process resource From: nlopess@php.net ("Nuno Lopes") OK, thanks for the feedback. It seems now I can commit it with confidence :) Nuno ----- Original Message ----- > 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