Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73254
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPhkiZxi0UxrrUMRNUFDmkzs2pX6y81PPabzLjLF-ChboaB8jg@mail.gmail.com>
References: <CAPhkiZw5xWRkc=ofh-nB5ZkjfThZFkH_+pK5RZaQFLKhno7u7A@mail.gmail.com>
 <CAGa2bXZiBuw_L_ehvTZb5_UUedtbS0n4GXYUjtKix0S9DX_8KQ@mail.gmail.com>
 <5324FE40.1070704@sugarcrm.com> <CAPhkiZy1oG_WHijMknB34dyo0aZRDU89EBafpaEGqGM32DCK0A@mail.gmail.com>
 <532603A0.8060802@sugarcrm.com> <CAPhkiZxdrxiKT3cTW9ra=0aFDKKP3-OpjmGdxqzHxu8YEUK2ww@mail.gmail.com>
 <CAGa2bXbH8WFp=8C-ON-1aAHLiyTsemVKMH+dGnqBSJAw5zw-GA@mail.gmail.com>
 <CAPhkiZx52CiKkk385itjEtg99ox3PHzXga9ZWDPbWiB2wRyH4g@mail.gmail.com>
 <CAGa2bXZGun=khdMZHzYoERap7qj7bQDPEfQzx2jJ2MwPs7-p_g@mail.gmail.com>
 <CAPhkiZzmzTqPR4KynBCWijvHa=TGKzTni7JdfuuKdy_i=sBeQg@mail.gmail.com>
 <CAGa2bXb6k8NYyYheCM6dvFWj-jA2GLP7ZiusTgZK-YgkNkeHhQ@mail.gmail.com>
 <CAPhkiZz-_PxvfsCiMDm8Hf9YzVNV+Ch1zpqDut19uV1w1WCWoA@mail.gmail.com>
 <CAGa2bXb45BizZ8g8zzdneV_27R7zgiX34xoZm+f8YyNQrZxdTQ@mail.gmail.com> <CAPhkiZxi0UxrrUMRNUFDmkzs2pX6y81PPabzLjLF-ChboaB8jg@mail.gmail.com>
Date: Tue, 18 Mar 2014 09:50:57 +0900
Message-ID: <CAGa2bXYajPoD6D34nPXvja-Xz+pc3bCwPi6f7U-5iA3=Z75h-w@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c377a43b91c104f4d6f0db
Subject: Re: [PHP-DEV] [RFC] Revert/extend/postpone original RFC about
 read_only, lazy_write sessions
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c377a43b91c104f4d6f0db
Content-Type: text/plain; charset=UTF-8

Hi all,

On Mon, Mar 17, 2014 at 7:47 PM, Andrey Andreev <narf@devilix.net> wrote:

> >> > 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.
>
> My quesion was rather why does it need to be optional at all
> (regardless of the default value)? If it is somehow handled at all
> times, it becomes just a performance improvement. I don't see a reason
> why performance improvements should be optional.
>

I agree.
If nobody objects, I'll remove the option. Please send mail ASAP!


>
> >> >> 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?
>
> I'm all for it (naturally, since I suggested it), it could be
> updateTimestamp(), updateTs(), updateTime(), etc. Anything in that
> fashion would be more descriptive and less confusing.


I agree this, too.
I would choose "updateTimestamp".
Please send mail ASAP, if anyone has comment.

When is the beta due? I made PR so that RMs can merge it.
I don't need git commit log. It's just a personal memo. Please feel free to
merge
 with squash if RMs are would like to merge it now. It's good enough for
beta.

https://github.com/php/php-src/pull/628

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c377a43b91c104f4d6f0db--