|
użytkowników online: 80
|
OPINIE UŻYTKOWNIKÓW
|
W takich dniach, jak ten, nie żałuję, że wykupiłem abonament. Korzystam z porad na tych stronach nawet kilkanaście razy w tygodniu i dzięki nim prace nad stronami dla klientów idą mi o wiele szybciej, a strony wyglądają bardziej profesjonalnie. Nie wiem, jak mogłem wcześniej pracować bez dostępu do porad w tym serwisie!
Wojciech Miszkiewicz
|
|
PODRĘCZNIK PHP 5.x, 4.x, 3.x - częściowo spolszczony / źródło: www.php.net
[Spis]
[A]
[B]
[C]
[D]
[E]
[F]
[G]
[H]
[I]
[J]
[K]
[L]
[M]
[N]
[O]
[P]
[Q]
[R]
[S]
[T]
[U]
[V]
[X]
[W]
[Z]
Rozdział 45. Extension Possibilities
As shown in Rysunek 44-1 above, PHP can be extended primarily at
three points: external modules, built-in modules, and the Zend
engine. The following sections discuss these options.
External modules can be loaded at script runtime using the
function dl(). This function loads a shared
object from disk and makes its functionality available to the
script to which it's being bound. After the script is terminated,
the external module is discarded from memory. This method has both
advantages and disadvantages, as described in the following table:
To sum up, external modules are great for
third-party products, small additions to PHP that are rarely used,
or just for testing purposes. To develop additional functionality
quickly, external modules provide the best results. For frequent
usage, larger implementations, and complex code, the disadvantages
outweigh the advantages.
Third parties might consider using the
extension tag in php.ini
to create additional external modules to PHP. These external
modules are completely detached from the main package, which is a
very handy feature in commercial environments. Commercial
distributors can simply ship disks or archives containing only
their additional modules, without the need to create fixed and
solid PHP binaries that don't allow other modules to be bound to
them.
User Contributed Notesarachnid at notdot dot net
10-Aug-2004 08:06
After writing a test module with logging to see just when the module does get loaded and unloaded, it appears the module gets loaded on server startup, once for each apache thread, and shutdown when a child terminates or the server shuts down, at least for PHP 4.3.7 as a DSO on Apache 2.
My Name
01-Jul-2004 01:24
Listing extensions in php.ini shouldnt avoid reloading the module each time the php script runs. Module startup and shutdown function calls shows that.
dlacct at hotmail dot com
13-Feb-2004 02:21
Creating dynamic extensions and listing them in your php.ini file should eliminate the overhead of having to issue a call to dl() on every script. Taking this approach gives you the benefit of a separate module without the performance hit.
|
