Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78794 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98656 invoked from network); 6 Nov 2014 08:33:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Nov 2014 08:33:34 -0000 Authentication-Results: pb1.pair.com smtp.mail=narf@devilix.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=narf@devilix.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.50 as permitted sender) X-PHP-List-Original-Sender: narf@devilix.net X-Host-Fingerprint: 209.85.218.50 mail-oi0-f50.google.com Received: from [209.85.218.50] ([209.85.218.50:54078] helo=mail-oi0-f50.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 54/BC-28384-D523B545 for ; Thu, 06 Nov 2014 03:33:34 -0500 Received: by mail-oi0-f50.google.com with SMTP id v63so407482oia.37 for ; Thu, 06 Nov 2014 00:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devilix.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qv7OkqDG7RL0MzJvSVVGuQDOqTOPIEqz0omsUMhQ5jo=; b=rk82fweD/rdADadNRIIJ9JtgEPE1PhZ1xf77C+MHsX+O2E9PLQJDWJ9sdcglXt0/Sb o2Rbh6LNN2vJymwyEnGUIZ610nd1vuzrsk2+xxr1yTSpe5zc84DnM1mPlxWFK1rJAb5a cUOM20wM2wcHoh8WuDE93hr2nrV0bzmMyxTgo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Qv7OkqDG7RL0MzJvSVVGuQDOqTOPIEqz0omsUMhQ5jo=; b=TFn4moT313kl2MSPtPHrN5NmiYq1UtsWnFcb13iiaoJQ0ggk8EsCNTSFylPrtv/wBl oSDGRKOkx9+0gITf+KPestLidKsUNilbsTLvFXkOc3VlmkcJO/e0z1zOzbuKhKXessVO u3PpeM1uyw/GgY7L2BBY7Q+ruQUu6qIf34OrM/mDmLxJQ+VuYpAd41pRbqMjWijnRvOs ngDNAycMVlTfk1uIezRFd6l08wDmYmDMV+r0Ltsfhq7WAS2E41Rkg+A7oXfJphoxqfOU td9khabxgRRc7OYgCvZY7T9lvsj20TgPgqYAZWFzdZhO8moBbzX9uRwZDw0+dT2Wc7WC aqsw== X-Gm-Message-State: ALoCoQkqgSuksLL50715eyZwc07bThw9yuKqOgP/HVtbRmOb3gr+IiNay0DivDADzLMluo5jIkKX MIME-Version: 1.0 X-Received: by 10.202.186.136 with SMTP id k130mr333431oif.94.1415262810832; Thu, 06 Nov 2014 00:33:30 -0800 (PST) Received: by 10.202.75.148 with HTTP; Thu, 6 Nov 2014 00:33:30 -0800 (PST) In-Reply-To: References: <424081508.1350448.1415209726279.JavaMail.zimbra@escapemg.com> <801152711.1350497.1415209768109.JavaMail.zimbra@escapemg.com> Date: Thu, 6 Nov 2014 10:33:30 +0200 Message-ID: To: Yasuo Ohgaki Cc: Ferenc Kovacs , Mark Caudill , Yasuo Ohgaki , julien pauli , Damian Wadley , PHP Internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Lazy writing in the session, session-lock-ini, and bug #68331 From: narf@devilix.net (Andrey Andreev) Hi Yasuo, On Thu, Nov 6, 2014 at 3:42 AM, Yasuo Ohgaki wrote: > Hi Andrey, > > On Thu, Nov 6, 2014 at 8:23 AM, Andrey Andreev wrote: >> >> Short-term fix for 5.6 is obviously to revert the commit. I was vocal >> mostly because of principle at the time, but this issue is an example >> why. > > > Did you? I don't think so. You think you know better what *my* motivation was? (don't answer) > The reason that I didn't provide that user land "update" API is your > objection. If it is included, user had control even in this case. But it would still be a BC break. Also, the commit we're talking about was made way before I objected anything, don't throw that one on me. >> A long-term "fix" for 5.6 would be what I've done in userland recently >> - continue to call SessionHandler::write() at all times, but _inside >> of it_ call touch() instead of fwrite() if there's no new data. That >> way custom session handlers wouldn't be affected, but the default one >> would still provide a performance boost. This is of course if we do >> want to keep the feature (I do), but considering that it was voted in >> a slightly different form ... I'm just being egoistic with this >> suggestion. > > > No. Providing userland update API just like C module save > handler is the way to go as I implemented at first. > > Besides, the method that you described will not solve the issue reported > by the bug. There is no point that provides different API for C and PHP > written save handlers, IMO. You're still thinking in the context of your RFC and the patch that was never merged. The issue at hand is that write() is not called and the method that I described clearly solves that issue. Whether you think that's "the way to go" is another story. >> For PHP7 though, I definately want a redesign of the session APIs and >> it's on my TODO list for when I have some spare time to work on it. > > > I think you have misunderstanding for session management. > > One example is that you don't understand nature of browser and server > communication. It's _asynchronous_ by it's nature, yet you insisted > _syncronous_ operation. Without this understanding, session cannot > be managed correctly/precisely. I am very well aware of how HTTP works, thank you. Due to lack of context and for the sake of remaining on good terms, I'll refrain myself from replying in a more elaborate manner. Cheers, Andrey.