Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73365
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain devilix.net from 209.85.213.47 cause and error)
MIME-Version: 1.0
In-Reply-To: <002f01cf4669$6e3b1570$4ab14050$@devtemple.com>
References: <002f01cf4669$6e3b1570$4ab14050$@devtemple.com>
Date: Sun, 23 Mar 2014 20:21:14 +0200
Message-ID: <CAPhkiZyub+HiJAYbChQJkCfn1J0dmHcpwGV_R5_fxiXzUaFxiw@mail.gmail.com>
To: Bill Salak <bill@devtemple.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: session_start read_only
From: narf@devilix.net (Andrey Andreev)

Hello,

On Sun, Mar 23, 2014 at 9:28 AM, Bill Salak <bill@devtemple.com> wrote:
> // $_SESSION['logged_in'] has been set in a previous request
> Request 1: session_start(['read_only' => TRUE]);
> Request 2: session_start(); unset($_SESSION['logged_in']); session_write_close();
> Request 1: if ($_SESSION['logged_in']) { /* logic */ } // evaluates to TRUE
>
> works the same way today that you describe as a problem, if I'm not mistaken.
>
>  - Request 1 locks the session and Request 2 waits.
>  - Request 1 finishes and unlocks the session.
>  - Request 2 can now get on with its work.

My example shows that Request 1 completes after Request 2, and that's
not the same thing. There were already multiple comments on that
example and it turned out not to be as clear as I thought. I'm working
on an updated version of the RFC, which would also provide a better
example.

> I initially suggested this "read_only" feature to Yasuo (as he has implemented it today) in order to solve this blocking wait time problem. The use case I wanted a solution
> for is common in the applications I design/work-on/see today which is modular AJAXy/independent access to PHP sessions, i.e. "is this user logged in and allowed to call this thing?"
> In these use cases I often know I just need to read the session data and will not write to it therefore I just want the lightest, quickest read-and-release-session process possible for
> near-concurrent access to reading the session. Actually writing+reading to a session (or any datastore for that matter) becomes a synchronicity issue which is fundamentally at odds
> with a codebase designed around asynchronous access to state and needs to be solved for by the application architecture/design in those situations that need to have that sort of
> protection. In other words, I believe the example problem use case you've posed is an application design problem not a language level issue IMO.

It is a design problem, but the 'read_only' name is highly misleading
(especially for an option to session_start()), which is a language
(design) level issue. It's a nice feature, but should be accessible
through better API.

> On a related note, your suggestion of a "true read only" implementation would presumably either throw an error on attempt to write to a session that was locked as "read only" or
> would act as sessions act today, which is to say, wait for the session to unlock before writing to it. My gut reaction is that neither of these are better than what we have today but
> the conversation is young and I'm interested to hear more.

That's a description of what the "read-only" term means, and hence -
why naming the current feature "read_only" is misleading. Whether
"true read only" is implemented or not is not what I'm interested in
right now, I'm not pushing for it.

> One last point, the ability to "configure" a session through an array of options is very useful from an end-user code design point-of-view. Moving the ability to start a session as read
> only to a separate function call than I would use to start a session otherwise forces choices in code design that can otherwise be much more elegantly handled through the use
> of a single function with a configuration parameter.

I love the ability to pass options to session_start(). :)
What I don't like is that session_start($options) could mean that the
session is closed immediately, it's counter-intuitive.

Cheers,
Andrey.