Hi! >> Document calling session_gc() periodically is the best practice. > > If you want to document usage of this new API as the best practice, it > would be unfair to the users if you don't also document the caveats that > come with it:
I also think it's wrong to document it so. While having periodical GC is the best practice, probabilistic GC *is* calling GC periodically. True, for some exceptional scenarios - like sites with very low traffic - the period is unpredictable. And *then* it's recommended to explicitly call session_gc(), and for these cases it is a great addition. But in a typical medium or high traffic site the period is very predictable as as such there's no way to document otherwise. > probability-based behavior (and how to do that; based on my > observations, the vast majority of users don't know how GC is triggered > at all) And that's great BTW since majority of users don't need to know that - it just works. We shouldn't ruin that. > - Trigger warnings when session_gc() is called while gc_probability is > not 0. This does not sound like a good idea to me. Why we should make it harder for people to use it together? session_gc() has nothing to do with gc_probability. > - To avoid re-activating expired sessions, trigger warnings when > session_gc() is called after session_start() Last time I've looked at the patch, session_gc() was required to be called after session start. See: https://github.com/php/php-src/pull/1852/files#diff-2e4264d70a35458a2241e27f76f4a93cR20 I think this is wrong (see my comments there) and in fact we should not expose this complexity to the user - gc() should just do the GC and hide the technical details. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
