Re: [PHP4BETA] sapi_xxx_module()

> A shared memory pool in a multiprocess environment is almost completely > useless. It's useless since you would want to use it for shared resources, > but since you don't control these resources, you can't do anything with > this shared pool. The most you'd be able to share through this pool is > zval's or the likes, and I doubt it's worth messing with shared memory for > those. Please define "control." > In both multiprocess and multithreaded environments, you would have to > protect any shared resources (ones you managed to actually use through > shared memory) from being accessed from more than one thread/process at the > same time. Yes. mm supports that using mm_lock/mm_unlock. Since mm was written to be used with Apache and thus in a multithreaded/preforked environment, I doubt we will hit any problems using it. > The way PHP 4.0 is designed, or rather, the way the thread-safe version of > PHP 4.0 was designed, was to emulate a multiprocess environment within a > multithreaded environment. That is, each thread has its own persistent > resources, that are managed independently from other threads. This makes > development of plugin modules identical under a multiprocess and a > multithreaded environment, as long as you follow some simple rules. Any > multiprocess plugin module can be converted to a thread safe module > (provided the underlying 3rd party library is thread safe, of course). > > From the experience we've gained in PHP 3.0, and the experience and > implementations of others (e.g., ODBC under Windows NT), if you want to > have resource pools, you should be using IPC and an established protocol > between the client (PHP) and the server. If you write a separate process > with which PHP speaks, that handles poolable resources - things would work > best. Nope, mm does not support that. You have to create the MM pool in the parent (process|thread) and pass it to your children. I've first thought about using IPC to pass a handle to the MM pool, but that is not possible. -- Regards, Sascha Schumann Consultant