ID: 47629 Updated by: [email protected] Reported By: danielc at analysisandsolutions dot com -Status: Open +Status: Bogus Bug Type: MySQLi related Operating System: Windows XP SP3 PHP Version: 5.3CVS-2009-03-12 (snap) New Comment:
. Previous Comments: ------------------------------------------------------------------------ [2009-09-17 11:40:03] [email protected] I don't see a bug here either. The windows binaries from php.net default to mysqlnd as of PHP 5.3. The PHP 5.2 ones should use the MySQL Client Library. The MySQL Client Library uses its own network layer abstraction whereas mysqlnd uses PHP streams. The default CONNECT_TIMEOUT of mysqlnd is 0, unless overruled by API settings (mysql.connect_timeout, MYSQLI_OPT_CONNECT_TIMEOUT, <whatever_may_set_php_streams_default>, ...). The MySQL Client Library uses the same default. Both PHP streams and the MySQL Client Library pass the value down to the network functions. Regarding READ_TIMEOUT please see http://bugs.php.net/bug.php?id=49511 . Seems that your main point is about the Fatal error. In my eyes this is what shall happen - no bug: "Note: The set_time_limit() function and the configuration directive max_execution_time only affect the execution time of the script itself. Any time spent on activity that happens outside the execution of the script such as system calls using system(), stream operations, database queries, etc. is not included when determining the maximum time that the script has been running. This is not true on Windows where the measured time is real.", http://de3.php.net/set_time_limit According to the documentation the time limit on Windows is real time. That is wall clock. The script should stop after max_execution_time - default_socket_timeout > max_execution_time does not matter. The question is if/why the timeout does not happen (on PHP 5.2, 5.3?) when using the MySQL Client Library on Windows. The way I read the manual time spend on database operations should be taken into account on Windows. And that is a matter of the PHP time limit functionality (-> Category: General/similar not MySQLi related) ------------------------------------------------------------------------ [2009-06-22 15:58:32] danielc at analysisandsolutions dot com I'll put together tests of the various functions and report back. ------------------------------------------------------------------------ [2009-06-21 09:04:11] [email protected] "1) That's how PHP 5.2 does it." Not really relevant in this case. "2) That's how the other socket functions do it in 5.2 and 5.3." Then there is a bug here. "3) The timeout is from communication with another entity, not from the script itself." The max_execution_time has the highest priority and should always has it. If it is not the case in one function or another then there is a bug in this function. ------------------------------------------------------------------------ [2009-06-21 00:48:41] danielc at analysisandsolutions dot com Because: 1) That's how PHP 5.2 does it. 2) That's how the other socket functions do it in 5.2 and 5.3. 3) The timeout is from communication with another entity, not from the script itself. ------------------------------------------------------------------------ [2009-06-20 20:12:24] [email protected] but there is no bug here. Why do you want to let the socket timeout override the main timeout? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/47629 -- Edit this bug report at http://bugs.php.net/?id=47629&edit=1
