Hi all,
On Mon, Mar 17, 2014 at 6:57 PM, Andrey Andreev <narf@devilix.net> wrote:
> On Mon, Mar 17, 2014 at 11:31 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> > On Mon, Mar 17, 2014 at 6:14 PM, Andrey Andreev <narf@devilix.net>
> wrote:
> >> Is there a default SessionHandler::update() method? If yes, how is
> >> that handled? That's supposedly just exposing the internal API and a
> >> user can choose whether to override one or many methods. But if all of
> >> them are overriden, how do you know it uses the same storage at all?
> >> And what if an existing userland handler already has an update()
> >> method that does something completely different?
> >
> >
> > There is dummy function for validateSid() and update().
> > Both returns true always.
> >
> > If save handler (regardless of user or C) does not implement its own
> > update(),
> > then update() will not be called, instead write() is called.
> > To do that, address of the dummy function is compared.
>
> Ok, so why is 'lazy_write' an option at all then? I don't see a reason
> why it shouldn't be the default and even mandatory behavior.
>
I would like to make 'lazy_write' default to TRUE, since there would not be
'unsafe_lock'.
I wouldn't try to add 'unsafe_lock' anymore. It's safe to make
'lazy_write'
default to TRUE.
'lazy_write' needs a little memory, but it's session. Session data would be
small enough
for almost all apps and memory is cheap these days.
(Note: I've implemented 'lazy_write' by using MD5 hash at first, but
benchmark revealed
simple store and string compare is much faster. It's saving loaded session
data and
compare to check modification with new patch.)
Any objection/comment make this default to TRUE or automatically apply
'lazy_write'?
I think automatically applying 'lazy_write' is good choice.
>> The devil is in the details and these details aren't explained
> >> anywhere, that's why I'm concerned.
> >
> >
> > Currently implemented save handlers work as it is now both user and C.
> >
> >> Btw, this should probably be called updateTimestamp() instead of
> >> update(), for userland at least. write() vs. update() can be somewhat
> >> confusing.
> >
> >
> > This could be changed. Better name is always good.
>
> Well, there you go - updateTimestamp() is a better name. ;)
I thought of similar name. I choose update() since it seemed it is matching
name for read()/write(), but descriptive name may be better.
Any comments for renaming?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net