Req #52173 [Com]: ext/pcntl doesn't store/report errors

From: Date: Thu, 24 Jun 2010 17:10:04 +0000
Subject: Req #52173 [Com]: ext/pcntl doesn't store/report errors
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-151847@lists.php.net to get a copy of this message
Edit report at http://bugs.php.net/bug.php?id=52173&edit=1

 ID:               52173
 Comment by:       nick dot telford at gmail dot com
 Reported by:      nick dot telford at gmail dot com
 Summary:          ext/pcntl doesn't store/report errors
 Status:           Open
 Type:             Feature/Change Request
 Package:          PCNTL related
 Operating System: Linux
 PHP Version:      trunk-SVN-2010-06-24 (SVN)

 New Comment:

I've attached a patch that implements solution #3.

The patch used the extent of my amazing copy/paste skills to extract the

posix_get_last_error() and posix_strerror() functionality from ext/posix
and 
duplicate it in ext/pcntl.

If there's anything wrong with this patch, please let me know. But let
me down 
lately - this is the first time I've written (if you can call it that)
any C, 
let alone worked on a PHP extension. We've all gotta start somewhere :)

If you need me to write tests etc. please let me know, also any tips on
how to 
go about doing so.

I've tested this using the example in the description and it works a
treat.


Previous Comments:
------------------------------------------------------------------------
[2010-06-24 18:19:05] philip@php.net

I like option #3.

------------------------------------------------------------------------
[2010-06-24 16:58:59] nick dot telford at gmail dot com

Minor addendum: A solid use-case as to why it is useful for the userland
code to 
read the error code.

When calling pcntl_wait(), -1 will be returned if there are no child
processes 
running (errno == ECHILD) and also if the call is interrupted by a
signal (errno 
== EINTR).

This makes determining whether there are children left to wait on
tricky, as -1 
could simply be an interrupt from a signal being handled.

------------------------------------------------------------------------
[2010-06-24 16:40:37] nick dot telford at gmail dot com

Description:
------------
The following ext/pcntl extensions "return -1 on failure", yet have
multiple 
possible reasons for failure: pcntl_fork, pcntl_wait, pcntl_waitpid

Each of these functions can fail for several reasons and in some cases 
(especially wait/waitpid) it is useful for the userland code to be able
to 
handle the different error codes.

The Linux man pages for fork(2) and wait/waitpid(2) all specify that the
error 
code is stored in "errno" when an error occurs. I only have experience
of the 
System V (Linux) way, so I'm not sure if this is interoperable, although
I 
believe so.

The ext/posix function posix_get_last_error() states that it returns the
error 
code for the last posix function that failed. Internally, all of these
functions 
also use "errno" to store the error code, but explicitly copy that to
another 
variable, which posix_get_last_error() returns 
(http://lxr.php.net/opengrok/xref/PHP_5_2/ext/posix/posix.c#1167)

I see two possible solutions, either:
 - posix_get_last_error() should be used to return these errors.
Although this 
would add a dependency between the two extensions.
 - An optional parameter, &$errno, should be added to pcntl_fork(),
pcntl_wait() 
and pcntl_waitpid() that is populated with errno if the result is -1.
 - A function is added to ext/pcntl, pcntl_get_last_error(), that
operates in a 
similar way to posix_get_last_error().

The third option seems simplest and most compatible, although I can't
help but 
feel these two extensions really belong together as one big happy
family. What's 
the reason they're separate in the first place?

Test script:
---------------
<?php
$pid = pcntl_wait($s);
var_dump($pid, posix_get_last_error());

Expected result:
----------------
int(-1)
int(10) # ECHILD

Actual result:
--------------
int(-1)
int(0)


------------------------------------------------------------------------



-- 
Edit this bug report at http://bugs.php.net/bug.php?id=52173&edit=1


Thread (5 messages)

« previous php.bugs (#151847) next »