Re: session_reset() and session_abort() to send errors

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.