Re: How do I make a dependency on the sockets extension?

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