https://bugs.php.net/bug.php?id=68331
I was hoping the submitter (or one of their coworkers who commented on
it) would reach out to the list themselves to get more information
since I don't know the whole situation. I did ask them to...
Story thus far:
Yasuo's session-lock-ini RFC [1] in February 2014 was (partially)
approved - the relevant change being that it adds support for lazy
writing. Optionally. There's a pull request with it that has NOT been
merged; as far as I can tell it's because there was discussion after
the vote raising problems and there was another RFC [2] (since
withdrawn) to change the first one. I also vaguely remember there
being merge problems between 5.6 and something?
Unrelated and prior to all this was a commit [3] in August 2013 for
request #17860 [4] that made session writes lazy for everyone. [see
session.c] Not optionally. It went into 5.6. Apparently this caused
problems for some people as they made 68331 a few days ago. I'm not
entirely sure that the userland code couldn't be changed to deal with
the lazy writing without requiring the crazy workaround they
described, but whatever I don't know their codebase.
I tried explaining that session-lock-ini is not yet merged, despite
being approved and being listed under the PHP 5.6 heading at /rfc, and
that the commit in question was entirely separate, to no avail.
Meanwhile I did NAB the bug on the grounds that the change was
intentional.
So what's up with the RFC and its code? Is it still happening for 5.6
(too late?) or 5.7 (I lost track if we're doing that) or 7? Any
suggestions for what I can tell the folks concerned?
-Damian
[1] https://wiki.php.net/rfc/session-lock-ini
[2] https://wiki.php.net/rfc/session-read_only-lazy_write
[3] https://github.com/php/php-src/commit/554021d21e1b2517313a377676260c188152c2eb
[4] https://bugs.php.net/bug.php?id=17860
Hi all,
Apparently this caused
problems for some people as they made 68331 a few days ago.
Just a quick note for this. The user would like to access session
data(session handler)
regardless of data modification. I suppose it could be solved if session
has user space
"update" handler as I suggested originally.
Alternatively, session_write_close()/session_commit() may be changed, so
that it
is called unconditionally during shutdown. I have to read the code to be
sure if this is possible.
BTW, anyone know the reason why the user need to call
session_write_close()/session_commit()
unconditionally? Accounting, perhaps?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
BTW, anyone know the reason why the user need to call
session_write_close()/session_commit()
unconditionally? Accounting, perhaps?
Releasing locks is one example. In userland implementations though, it
could be all kinds of application-specific logic.
Cheers,
Andrey.
HI all,
Apparently this caused
problems for some people as they made 68331 a few days ago.Just a quick note for this. The user would like to access session
data(session handler)
regardless of data modification. I suppose it could be solved if session
has user space
"update" handler as I suggested originally.Alternatively,
session_write_close()/session_commit() may be changed, so
that it
is called unconditionally during shutdown. I have to read the code to be
sure if this is possible.BTW, anyone know the reason why the user need to call
session_write_close()/session_commit()
unconditionally? Accounting, perhaps?
The issue user has reported could be solved easily by calling write API
during shutdown, IIRC.
An explicit flag for this might be needed.
I'm just curious for what reason the user needs to call
session_write_close() during shutdown.
It could be used as user states in old PHP, but it does not make it valid
usage/design automatically,
so I wander the reason.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
HI all,
Apparently this caused
problems for some people as they made 68331 a few days ago.Just a quick note for this. The user would like to access session
data(session handler)
regardless of data modification. I suppose it could be solved if session
has user space
"update" handler as I suggested originally.Alternatively,
session_write_close()/session_commit() may be changed, so
that it
is called unconditionally during shutdown. I have to read the code to be
sure if this is possible.BTW, anyone know the reason why the user need to call
session_write_close()/session_commit()
unconditionally? Accounting, perhaps?The issue user has reported could be solved easily by calling write API
during shutdown, IIRC.
An explicit flag for this might be needed.
There already is such explicit flag in PHP 5.4's OOP version of
session_set_save_handler().
The linked test script in the bug report also explicitly registers
session_write_close() as a shutdown function.
The problem isn't that there's no call, it's that the call itself is ignored.
Cheers,
Andrey.
Hi Andrey,
The problem was "there was partial patch, while patch that overwrite it
was not merged". I was confused.
Offensive patch is removed for now already and this issue is closed.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi,
HI all,
On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley php@requinix.net
wrote:Apparently this caused
problems for some people as they made 68331 a few days ago.Just a quick note for this. The user would like to access session
data(session handler)
regardless of data modification. I suppose it could be solved if session
has user space
"update" handler as I suggested originally.Alternatively,
session_write_close()/session_commit() may be changed, so
that it
is called unconditionally during shutdown. I have to read the code to be
sure if this is possible.BTW, anyone know the reason why the user need to call
session_write_close()/session_commit()
unconditionally? Accounting, perhaps?The issue user has reported could be solved easily by calling write API
during shutdown, IIRC.
An explicit flag for this might be needed.There already is such explicit flag in PHP 5.4's OOP version of
session_set_save_handler().
The linked test script in the bug report also explicitly registers
session_write_close()as a shutdown function.The problem isn't that there's no call, it's that the call itself is
ignored.Cheers,
Andrey.
Hi Damian,
I've reverted incomplete patch for the RFC.
Since the RFC patch
https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lock
was not merged yet, it has to be removed for now.
We have to decide what to do with the RFC, but it should be different
thread.
Thank you for reporting.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
2014.11.06. 6:02 ezt írta ("Yasuo Ohgaki" yohgaki@ohgaki.net):
Hi Damian,
I've reverted incomplete patch for the RFC.
Thanks!
Since the RFC patch
https://github.com/yohgaki/php-src/compare/PHP-5.6-rfc-session-lock
was not merged yet, it has to be removed for now.We have to decide what to do with the RFC, but it should be different
thread.
Thank you for reporting.
I think it could have stayed in the same thread (as this thread wasn't just
about the bugreport but also about the partially accepted but never merged
rfc) but maybe it is better to separate, I'm just a bit afraid that the
context will be missing for those who only read that thread, but not this.