Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73132 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 1076 invoked from network); 13 Mar 2014 22:01:55 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Mar 2014 22:01:55 -0000 Authentication-Results: pb1.pair.com header.from=yohgaki@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=yohgaki@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender) X-PHP-List-Original-Sender: yohgaki@gmail.com X-Host-Fingerprint: 209.85.217.170 mail-lb0-f170.google.com Received: from [209.85.217.170] ([209.85.217.170:58958] helo=mail-lb0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1F/E9-47923-1DA22235 for ; Thu, 13 Mar 2014 17:01:54 -0500 Received: by mail-lb0-f170.google.com with SMTP id s7so1169109lbd.29 for ; Thu, 13 Mar 2014 15:01:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=GSpGStITuLwOvUlkBx/MhBN8bdodcLw+GbB6mWj3TlM=; b=iHz97S3scaQN/jmXExiIxiXGx07Xrsz0jkwW/pKJm5SlmTFW3XNRFbIDmAIX/Ix/Xw XMTtTegko9x0YgTFUGT1W0z/A0r0Jm1p7aSmd7VsM7sZ9Ty+goTCr0ZOdBxVDxkRV3UA BOC4FZDgqUWuSOTAWwBnoGakdH2u+Bd5B27Jw12jj9MSdZfUwZxQJCvaKKB7rF75IUmD ldCPSc//BuJxx1pcdH7DEXg0kaxu2pCRP3VmxGy9FcTRkDKz4z2BAAZDwmXsOe7cTTxT a2zoOCz5kHieNbtJstrj0fcjQVFhXHZnYkMhpy4Z5mQw6wN68qCZCWmL+4uUjAYgRE8f 4HwQ== X-Received: by 10.152.36.199 with SMTP id s7mr328195laj.48.1394748110437; Thu, 13 Mar 2014 15:01:50 -0700 (PDT) MIME-Version: 1.0 Sender: yohgaki@gmail.com Received: by 10.112.205.73 with HTTP; Thu, 13 Mar 2014 15:01:10 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Mar 2014 07:01:10 +0900 X-Google-Sender-Auth: qCo8f_qSOCLnt7R9JMHjjfZI9QI Message-ID: To: Andrey Andreev Cc: Pierre Joye , Patrick Schaaf , internals Content-Type: multipart/alternative; boundary=089e0160bb12ac848904f48419eb Subject: Re: [PHP-DEV] Re: Revert session_serializer_name(), session_gc() From: yohgaki@ohgaki.net (Yasuo Ohgaki) --089e0160bb12ac848904f48419eb Content-Type: text/plain; charset=UTF-8 Hi Andrey, On Fri, Mar 14, 2014 at 6:01 AM, Andrey Andreev 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 yohgaki@ohgaki.net --089e0160bb12ac848904f48419eb--