Re: session_reset() and session_abort() to send errors
Hi,
On Fri, Apr 4, 2014 at 12:48 PM, Yasuo Ohgaki <[email protected]> wrote:
> Hi Andrey,
>
> On Tue, Apr 1, 2014 at 6:20 PM, Andrey Andreev <[email protected]> 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.
Thread (15 messages)