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

Hi Andrey, On Fri, Apr 4, 2014 at 7:07 PM, Andrey Andreev <narf@devilix.net> wrote: > 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. :) > Regarding to safety of session data management, session management is _not_ safe anyway. Locked session does not guarantee data consistency due to nature of HTTP session management. Locked session provides a litter better consistency. That's all and no more than that. i.e. It's false sense of safety. That said better is better. That's the reason why I'm proposing various _better_ way of management than now. >> 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. It's not trade. session_gc() is mandatory and I'll add it anyway :) Periodic GC is much better way than probability based GC. There must be API for it. I think there wouldn't be argument for this. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net