Hi Andrey,
On Fri, Mar 14, 2014 at 6:01 AM, Andrey Andreev <[email protected]> wrote:
> > Shared lock could be used easily for some session storage, but it
> requires
> > save handlers modification and it could be implemented _independent_ of
> > read_only. Web apps must return response ASAP. Therefore, any locks that
> > could be avoided should be able to be avoided including read(shared)
> lock.
>
> I'm talking about handlers that PHP itself ships, they all implement
> locking (exclusive locking).
>
> An exclusive lock can only be obtained by one process and all others
> will have to wait for it to be freed.
> A shared lock can be acquired by multiple processes and as such, is
> concurrency-friendly. However, it is only usable if sessions are in
> read_only mode, hence why I'm suggesting it.
>
read_only mode is "read and finish session".
Shared lock is "can read session, but not write".
Semantics differs.
>
> > Anyway, read_lock is confusing unless save handler API supports it. i.e.
> > User cannot know if it really support read_lock like current
> > use_strict_mode.
>
> Users needs to know if they are in read_only mode.
> Currently they can't, because the RFC proposed it an obscure setting
> available only to session_start(). If it was an INI setting, it
> could've been readable.
>
I like INIs. Therefore, it was INI initially.
It was made to start option, since others do not like INIs.
> Why not write a RFC for read_lock? I'm OK to implement it if you would
> like.
>
> Because this is one of the few session-related things that doesn't
> need an RFC, but rather common sense.
> It's just an implementation detail that was not described in the RFC.
>
My common sense tells that there should be session_gc(), there should be
session_serializer_name() if there is session_module_name ;)
However, I like the idea of getting rid of INI modifying functions. I'm OK
with either
- have both session_module_name() and session_serializer_name()
- getting rid of them all
The RFC was made with long discussions. It involves other RFC, too. I may
miss to write some and it may be difficult to understand reason behind it.
I'll answer if there is questions. Please don't forget to write your reason
why feature should be changed.
Regards,
--
Yasuo Ohgaki
[email protected]