Morning Yasuo, > Mm save handler does not compile with ZTS currently.
libmm is not intended for use in multi-threaded environments ... mostly because threads don't need to map memory to share, they are already in the same address space. Another problem is processing models. PHP in NTS mode is highly likely to be deployed in some prefork multi processing model, this is a suitable environment for sharing with mapped memory. In ZTS mode, multi processing models are different, they are not always prefork, and so it's not always possible to share memory, nor is it always possible to create the right kind of synchronization primitives, some systems just lack that ability. There's probably not much point in trying to do anything about the mm handler, I doubt it is really used that much ... Cheers Joe On Tue, Apr 26, 2016 at 10:38 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi all, > > On Tue, Apr 26, 2016 at 4:44 PM, Remi Collet <r...@fedoraproject.org> > wrote: > > Le 25/04/2016 à 16:09, S.A.N a écrit : > >> In userland lacks the ability to store data in the shared memory > >> modules, do not use pecl modules, it would be very nice to have a > >> function: > >> > >> opcache_get($key); > >> opcache_set($key, $value); > > > > Opcache is an opcode cache. > > > > A user data cache is something really different. > > > > We learn from the past, having both in the same extension (APC) was an > > mistake. > > > > So I really think, this doesn't have to be added in opache. > > > > And various extensions already exist (apcu, yac, memcache(d), redis...) > > each for different needs. > > They are different thing. That said > > Are we going to have race condition free shared memory API by default? > > If yes, I'll use it for mm save handler (session save handler that > uses shared memory) storage. Mm save handler does not compile with ZTS > currently. Mm save handler would be nice for small web sites. It could > be default save handler and many apps/sites will have performance > boost. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
