On Thu, 29 May 2003, Wez Furlong wrote:
>It looks like there was some code in the apache SAPI to avoid this
>problem, but it is currently commented out with an explanation that it
>is "problematic".
What code exactly..? Maybe ask that who commented out why it was problematic?
--Jani
At 22:44 29/05/2003, Wez Furlong wrote:
Under apache, you inherit all of the apache sockets when the libc forks
and execs your script.
This causes some problems (there are one or two bug reports about this
in the bug db) with processes waiting around on the sockets.
It looks like there was some cod
I think I did check, but there were no useful comments.
if close()ing them before exec'ing is a problem, can't we just set the
close-on-exec flag on the fd's ?
This will cause the descriptors to be dup'd for the fork, and the
duplicates to be closed when the child execs; in theory, that will leave
At 17:44 30/05/2003, Wez Furlong wrote:
I think I did check, but there were no useful comments.
if close()ing them before exec'ing is a problem, can't we just set the
close-on-exec flag on the fd's ?
This will cause the descriptors to be dup'd for the fork, and the
duplicates to be closed when the
So, does this mean that because of FP, we are stuck? There is something sad
about that. But, Brian Foddy emailed me a work around to my solution.
| I don't know if this helps, or is restating the obvious...
| Using 4.2.3 and apache 1.3.21 (php_mod) (yes, rather old combo, hopefully
| this behavi
I *think* that in the case of Brian's question (which applies to the
exec(), system() and so on family of PHP functions), we can safely loop
throught the descriptors (except for those we will be using to capture
or pass-thru the output) and set the close-on-exec flag prior to
forking.
I don't have
At 18:02 30/05/2003, Wez Furlong wrote:
I *think* that in the case of Brian's question (which applies to the
exec(), system() and so on family of PHP functions), we can safely loop
throught the descriptors (except for those we will be using to capture
or pass-thru the output) and set the close-on-e
For exec() and system(), we don't send any input and only capture
stdout. So, everything except the stdout fileno can be closed-on-exec.
The user can do the usual 2>&1 trick to get the stderr output as we run
their command using the shell.
--Wez.
On Fri, 30 May 2003, Zeev Suraski wrote:
> At 18
Hi:
Given the following script, which uses assert to eval() a string that
references the current class:
foo == 1'); }
function as_expr()
{ assert($this->foo == 1); }
}
$foo = new foo();
$foo->as_expr();
$foo->as_string();
?>
PHP 4.3-cvs executes it correctly, but PHP 5.0-cvs wi
At 18:18 30/05/2003, Wez Furlong wrote:
For exec() and system(), we don't send any input and only capture
stdout. So, everything except the stdout fileno can be closed-on-exec.
The user can do the usual 2>&1 trick to get the stderr output as we run
their command using the shell.
Unless I'm missing
When changing a ini entry with zend_alter_ini_entry during runtime the
Callback routines OnUpdate are never called. This problem only exists
in multithreaded environments.
I think that the handler field in the entry is not copied when creating the
copy of the ini entries after creating a new
Hopefully attached.
--Jani
--
Donate at: https://www.paypal.com/affil/pal=sniper%40php.net
All donated funds will be used for recreation :)
? fd_patch
Index: NEWS
===
RCS file: /repository/php4/NEWS,v
retrieving revis
Before we apply the patch we should look through it and remove things that
do not have to do something with the fd-lexer.
Instead of taking your patch we should use the last version of saschas
patch and add the "zend_file_handle fh = {0}" initializations in the
browscap and sapi modules by hand.
Does it include fixes to the bugs that were discovered in it?
Edin
On Sat, 31 May 2003, Uwe Schindler wrote:
> Before we apply the patch we should look through it and remove things that
> do not have to do something with the fd-lexer.
> Instead of taking your patch we should use the last versio
Attached real, working patch.
It reverts the unwanted CGI/CLI changes Marcus committed.
(the long opt and the obfuscated opts patch)
This patch also saves some other changes previous one reverted. :)
--Jani
--
https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note
At 02:29 31.05.2003, Jani Taskinen wrote:
Attached real, working patch.
It reverts the unwanted CGI/CLI changes Marcus committed.
(the long opt and the obfuscated opts patch)
The long opts are wanted, they make us compatible with other programs and
make CLI/CGI more user friendly. The "
The domxml extension is casting pointers to int. The patch below fixes
this for most 64-bit platforms, maybe there is a better way which avoids
casting to an integer at all?
--- php-4.3.2/ext/domxml/php_domxml.c.domxml2003-05-13 15:42:23.0 +0100
+++ php-4.3.2/ext/domxml/php_domxml.c
At 01:18 31.05.2003, Uwe Schindler wrote:
When changing a ini entry with zend_alter_ini_entry during runtime the
Callback routines OnUpdate are never called. This problem only exists
in multithreaded environments.
I think that the handler field in the entry is not copied when creating
the co
Its the same in the other way without PHP_INI_SYSTEM. They get changed.
Only the handler is not called.
At 12:32 31.05.2003 +0200, you wrote:
At 01:18 31.05.2003, Uwe Schindler wrote:
When changing a ini entry with zend_alter_ini_entry during runtime the
Callback routines OnUpdate are never
Any ideas what happened to
php.net/distributions/fd_patch-php-4.3.2.diff.gz? I committed it the same
day I reverted the fd patch, and yet there are no traces of it on cvs.php.net.
I recommitted it out of my old checkout, this is exactly what I reverted.
Zeev
At 02:25 31/05/2003, Jani Taskinen
Hi,
is anyone sucessfully using the oci8 Oracle extension on MacOSX?
Whenever I try to connect using OCILogon(), oci8 crashes:
May 30 00:33:19 localhost crashdump: Unable to write crash report to
/Library/Logs/CrashReporter/httpd.crash.log for uid: 70 Date/Time:
2003-05-30 00:33:19 +0200 OS
21 matches
Mail list logo
