On 09/06/2013 05:54 PM, Johannes Schlüter wrote:
On Fri, 2013-09-06 at 13:55 +0200, Julien Pauli wrote:
I'll consider checking for presence of sockets in the module registry.
However, I'm afraid it'll influence on performance too much in my case. So
likely I'll make sockets ext. required eventually.
You might cache it, while a zend hash find is an O(1) operation (and if
needed with pre calculated hash really fast)
But, wouldn't it be better to check for sockets' presence only once in the
MINIT phase?
Yes but, ext/socket could get registered after you, so in your own MINIT
you wouldn't notice its presence yet.
(Extensions are loaded in alpha order, but you shouldn't rely on that).
I still have a project of refactoring extension system for 5.6 , one of the
feature would be to keep hands on extensions loading order ;-)
This is not fully true. Yes, by default PHP will sort them when
statically building, but dependencies are handled (by pushing extensions
with uncleared dependencies back), shared extensions are loaded in order
of their extension= declarations in php.ini and there alphaet comesback
into play as php.ini files in ini dir are loaded in alphabetical order,
so distributors and users can define the order in filenames (prefix with
"z" to go last or use numbers etc.)
As said on IRC you have the following options, which all have downsides:
* Enforce sockets always. benefit: Easy and reliable to implement.
Downside: Strong requirement.
* Add an --enable-myext-sockets configure option. Benefit:
Flexibility. downside: most users will keep the default, more
work for testing
* try to autodetect using #ifdef. Benefit: relatively easy to
implement. Downside: Magic harder to predict for users, issue
with shared extension
* Always compile in the support and have runtime checks preventing
those code paths. Benefit: nicemagic. Downside: You rely on the
loader/runtime linker to do lazy loading of symbols, else the
user will receive bad errors
* Use some dlopen(NULL); dlsym(); magic. Benefit: Really nice
magic. Downside: dlopen works slightly different on different
systems.
* In your extension provide hooks and have a second extension
having strong dependency on socket and your primary extension
using those hooks. Benefit: Nice way to handle the dependency.
downside: Extra extension to maintain and install.
All those ways are not the single silver bullet. The question is how
central that socket functionality is and to some degree what kind of
users you want to reach. If you think it is relatiely important as
feature the first option is the best. And then beg either for users who
understand what they do and distributors to handle dependencies for
everybody else. Last way can be nice if this enables a distinguished
feature not everybody needs.
johannes
I made it required, but the user can still disable it explicitly via
--disable-event-sockets:
https://bitbucket.org/osmanov/pecl-event/commits/1db0ab4b47d9335b7bb1fba2aa25485a2803906e#chg-config.m4
--
Ruslan Osmanov
--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
