> If his cache had no locking before, what changed?
Well, I have been using several cache classes. A good cache class is the
pear cache light.
This cache is serializing your data and write this data to a file - of
course with file locking.
I could imagine, that a improved serialize-function coul
On Tue, 8 May 2007, Richard Lynch wrote:
> On Tue, May 8, 2007 1:17 am, Derick Rethans wrote:
> > On Mon, 7 May 2007, Lukas Kahwe Smith wrote:
> >
> >> Stanislav Malyshev wrote:
> >> > > can write this data to disk. So, you needs 20MB. If serialize
> >> > > (and of course unserialize) would be ab
On Tue, May 8, 2007 1:17 am, Derick Rethans wrote:
> On Mon, 7 May 2007, Lukas Kahwe Smith wrote:
>
>> Stanislav Malyshev wrote:
>> > > can write this data to disk. So, you needs 20MB. If serialize
>> (and of
>> > > course unserialize) would be able to write directly to disk (or
>> read
>> > > dire
Well as the topic implies I am quite sure that the user request was
about caching into a custom file and not inside the session. Both are
frequent use cases.
If his cache had no locking before, what changed?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Stanislav Malyshev wrote:
? Nobody is talking about sessions here, just about the serialize()
You mean you are not talking about sessions. I, however, do. Sessions
are one of the obvious examples where such functionality could improve
performance.
Well as the topic implies I am quite sure t
? Nobody is talking about sessions here, just about the serialize()
You mean you are not talking about sessions. I, however, do. Sessions
are one of the obvious examples where such functionality could improve
performance.
function that is also used for a myriad of other things...
Oh reall
On Tue, 8 May 2007, Stanislav Malyshev wrote:
> > on every fwrite. And you can not first cache it in memory as you then lose
> > the whole advantage of this idea.
>
> IIRC sessions are locked by php anyway, and for other uses if locking is
> important it is already implemented anyway, so we shoul
on every fwrite. And you can not first cache it in memory as you then
lose the whole advantage of this idea.
IIRC sessions are locked by php anyway, and for other uses if locking is
important it is already implemented anyway, so we shouldn't really try
to solve all the world's problems with th
On Tue, 8 May 2007, Stanislav Malyshev wrote:
> > If we're to add this, make sure writes to the files are atomic.
>
> Does PHP now ensure fwrite is atomic? If it doesn't than writing on serialize
> doesn't change a thing.
Only "a" mode is atomic - per write call; normal fwrites are not.
However
If we're to add this, make sure writes to the files are atomic.
Does PHP now ensure fwrite is atomic? If it doesn't than writing on
serialize doesn't change a thing.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Developmen
On Mon, 7 May 2007, Lukas Kahwe Smith wrote:
> Stanislav Malyshev wrote:
> > > can write this data to disk. So, you needs 20MB. If serialize (and of
> > > course unserialize) would be able to write directly to disk (or read
> > > directly from disk), you only needs 10MB.
> >
> > Actually having s
Stanislav Malyshev wrote:
can write this data to disk. So, you needs 20MB. If serialize (and of
course unserialize) would be able to write directly to disk (or read
directly from disk), you only needs 10MB.
Actually having serialize/unserialize be able to write directly to a
stream and read d
can write this data to disk. So, you needs 20MB. If serialize (and of
course unserialize) would be able to write directly to disk (or read
directly from disk), you only needs 10MB.
Actually having serialize/unserialize be able to write directly to a
stream and read directly from a stream might
13 matches
Mail list logo
