Re: [APC-DEV] Re: [PECL-CVS] cvs: pecl /apc apc_optimizer.c apc_optimizer.h

Not sure about the second one, I've always been under the assumption  
that dlsym only operates on dynamically loaded libraries using the  
dlopen function.  I'm also assuming that you  would be unable to  
lookup a function in a statically compiled binary with the symbols  
stripped.  The first seems to be the standard setup for this that  
I've seen elsewhere in the codebase, and seems fine to me.  Although  
it would be very useful to know if it's possible to call a function  
from a static library as described in the second.  One request on the  
first method would be to have the apc_register_optimizer function  
return the original value so that you could have multiple  
optimizers.  This is currently possible with many of the globally  
defined hooks in php, so that they can be "daisy chained" or  
temporarily circumvented.

-shire

On Dec 7, 2006, at 11:06 PM, Gopal Vijayaraghavan wrote:

> Brian Shire wrote:
>> Let me know if you want me to work that up Gopal, seeing as I'm  
>> the complaining party.  ;-).
>> On Dec 7, 2006, at 2:16 PM, Ilia Alshanetsky wrote:
>>> I see no issue with removing the files, just give a way to  
>>> provide a hook. Ideally something that gets passed the oparray  
>>> and TSRM bits.
>
> What do you say about
>
> typedef apc_optimize_function_t  zend_op_array* (*f)  
> (zend_op_array* TSRM_DC);
>
> apc_register_optimizer(apc_optimize_function_t optimizer);
>
> *OR*
>
> OR even much more simply, I could do it similar to the way I use vld
> (for debugging) right now.
>
> optimizer = dlsym(NULL, "xyz_optimize_oparray");
>
> Either way, hooking into the optimizer inside APC ensures that
> oparrays which are filtered will not be optimized unnecessarily.
>
> The second method is my favourite, but I'm not quite sure about
> portability.
>
> Cheers,
> Gopal
> -- 
> If I learn from my mistakes, pretty soon I'll know everything.

-Brian Shire
  [email protected]
  [email protected]
  aim: int80h