Re: session_start() should not reset $_SESSIOn if it's not empty

Am 28.07.2017 um 14:48 schrieb Rowan Collins:

On 27 July 2017 18:03:23 BST, "lists@rhsoft.net" <lists@rhsoft.net> wrote:

if that could work in the way that session_start() keeps the current state of $_SESSION if not empty it would be possible to put the APCU-Read and if exit($apcu_content); before session_start() which would gain another 30% performance

I think that behaviour would confuse more people than it would help. If anything, it should be an error to access $_ SESSION if no session is currently open - if there is no session, the array has no meaning. (Arguably, all the other superglobals should be read only for the same reason, but that would be a huge break now.)

make them readonly would break my whole codebase including autotests and code-coverage tools because it is legit to as example fill $_SERVER['SERVER_NAME'] with specific informations to define a straight behavior when running in cli-test-mode instead wrap every basic thing in function calls - at the curretn state a core-cms cache-hit has a total of 32 funtion calls including PHP internal ones hence that 3 bugreport are becoming a MAJOR PROBLEM because the system itself is so fast that under load after a short time you get problems with dattabase connections and with persistent connections because of the third one after the load is gone any strict-typed application jsut breaks horrible https://bugs.php.net/bug.php?id=74971 https://bugs.php.net/bug.php?id=74970 https://bugs.php.net/bug.php?id=74967

If I understand you right, the scenario you describe is "I don't want to start a session yet, but if and when I do, I want to put this data into it". It feels like that could be adequately handled in userland with a wrapper object (or global var and functions if you prefer), which reads to and from $_SESSION when a session is open, but a a holding array when it's not yet.

that don't work because at this point you don't know in userland if you started a completly new session which should be initialized with values for follow-up requests or use the existing values from a previous request - at least not without writing ugly code session_start() knows that and would only need a flag if it is desired to bail out as you said above or as for this case init the session with specific values