Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71785
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.44 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAGa2bXY+9sEnBTi2s9kXDWSAONGvMywGoxRcOEyrFG5ODoKTsw@mail.gmail.com>
References: <CAGa2bXZEXx7H+atr3LK8OLLQGSd9a-6+Gey+RhPwP0d7EvTBmw@mail.gmail.com>
 <52E9A631.5050808@sugarcrm.com> <CAGa2bXYn8i9R2+FGMUeyrr00MjRMug5QhheLa=gLKSOc+0j-CA@mail.gmail.com>
 <18069656.FoN8fZuO6C@rofl> <CAJ26g5TtWDjoB3heP1n3JRmakrxWn622PiiBb4z5ruR=GO5Rcw@mail.gmail.com>
 <CAJ26g5TnAqeU4mpSfav7j+CDwBrfL_XRuzNrXpBuc6xrN14ewA@mail.gmail.com> <CAGa2bXY+9sEnBTi2s9kXDWSAONGvMywGoxRcOEyrFG5ODoKTsw@mail.gmail.com>
Date: Thu, 30 Jan 2014 16:31:51 +0900
Message-ID: <CAGa2bXadJUU520_tN5GoO5V7_J9EF=KG9=neKBRdutRGoCRd+Q@mail.gmail.com>
To: Patrick Schaaf <bof@bof.de>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013d1a7869ef9b04f12b0f48
Subject: Re: [PHP-DEV] Re: [VOTE] Introduce session.lock, session.lazy_write
 and session.lazy_destory
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e013d1a7869ef9b04f12b0f48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all,

On Thu, Jan 30, 2014 at 4:17 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> On Thu, Jan 30, 2014 at 3:37 PM, Patrick Schaaf <bof@bof.de> wrote:
>
>> Unrelated to the previous discussion, and applicable to the base PHP cod=
e
>> in mod_files.c too, another observation:
>>
>> Some syscalls can fail with EINTR, when a signal hits while within the
>> kernel. This is especially true for flock(LOCK_EX) because in the
>> already-locked case the second call will go to sleep for a while waiting
>> for the lock to clear. But it is also possible, I think, for the
>> pread/read/write calls. The usual handling for the case (-1 return && er=
rno
>> =3D=3D EINTR) is to just repeat the call in a while loop. I think that a=
t least
>> doing so for the LOCK_EX calls, would be prudent.
>>
>> best regards
>>
> I also notice other issue when closely looking at current code.
> It does
>
> open()
>  =E2=86=93
> read() - locked
> =E2=86=93
> script execution
> =E2=86=93
> write() - unlock
> =E2=86=93
> close()
>
> However, when write() is called, it always close opened fd to address
> changed session ID.
> This logic will likely to create race condition that reads old session
> data before writing.
>
> I'll address this issue as other issue to be fixed.
>
> In short, session data access is not serialized like serializable
> transaction isolation level.
>

It seems we have to keep all opened fd until session is really closed.
It requires rather large change. I'll fix this issue when this RFC is done.
Is anyone has better idea rather than keeping all fds?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e013d1a7869ef9b04f12b0f48--