Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73595
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbHomZmh91wk-5=LHG7S2FSbxTUnD+M=E9756WxFwYmHg@mail.gmail.com>
References: <CAMUwpuSVE4iMA86bxXUnvYLonJ3xmDZ_QSzM38eNvJibxcv6Xw@mail.gmail.com>
	<CAGa2bXYO6s6sQo0UkuRSaSciU1XVCHhWqc5MHCDL1H15ChZ65Q@mail.gmail.com>
	<CAMUwpuQePpm3FLY27ptvPyBU=kndK805D8sRr5N3GSoTQiiGxw@mail.gmail.com>
	<CAPhkiZy=y7AAfwtNPgPgfEWvLyv+aOnU=Yi_XKTYsszB7dS74g@mail.gmail.com>
	<CAGa2bXZJN72Z+L24NxVNT0A0sdojr8tJ4E5TPjYUTnjvSWkPig@mail.gmail.com>
	<CAPhkiZzBOM_jAm_tz2YKpj_ExJRUuP8y2dHBy4tm3+6KeHNiCQ@mail.gmail.com>
	<CAGa2bXaau5peLX=dh+6OUtOxKdYsHQzzdJktiXmDqb5UmXB96A@mail.gmail.com>
	<CAPhkiZy_1mQ4WGz1CiKiiC32i_oOVyfkTu===QZjV=UtWY6mKA@mail.gmail.com>
	<CAGa2bXbHomZmh91wk-5=LHG7S2FSbxTUnD+M=E9756WxFwYmHg@mail.gmail.com>
Date: Fri, 4 Apr 2014 13:07:56 +0300
Message-ID: <CAPhkiZxcWa+bwMOOMcjnTThY_CTRK5r5K7HWCFqHhKVUbqN7dA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Julien Pauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: session_reset() and session_abort() to send errors
From: narf@devilix.net (Andrey Andreev)

Hi,

On Fri, Apr 4, 2014 at 12:48 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> Hi Andrey,
>
> On Tue, Apr 1, 2014 at 6:20 PM, Andrey Andreev <narf@devilix.net> wrote:
>>
>> >> Well, I just re-checked it and does indeed just call
>> >> php_session_initialize(), so what's the point? Shorthand for
>> >> session_abort() && session_start() ?
>> >
>> >
>> > Yes, it's an API for it.
>> > It's more efficient than user land functions as it requires needless
>> > close and open (and initialization required to open).
>>
>> I'm confused now, does it call open() or does it not?
>> If it doesn't - it's unsafe.
>
>
> It's safe as long as handler locks data during read/write.
> Example is memcached save handler with unlocked session.

I had something other in mind and you didn't really answer my
question, but ... there you have it - it can be unsafe even by your
own words. :)

>> If it does - it's unclear, redundant and optimizes by silently
>> discarding already open resources (without properly closing them).
>>
>> Either way, I like efficiency but I also see it as flawed.
>
>
> Save handler may lock/unlock session data. There is no standardized
> way for it.
>
> Since there would not be lock option for session manager, I don't mind
> removing it. There is not much point to have it without lock option for
> session manager. I would like to have session_gc() than session_reset().

This sounds a bit like you're proposing some kind of a trade
agreement. When you put it that way, I'd also rather have session_gc()
instead of session_reset(), but that's not the point. My initial
argument was that these features need to be brainstormed here on
internals and there was no discussion about them at all.

Cheers,
Andrey.