Re: RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
| From: | Dmitry Stogov | Date: | Tue, 17 Mar 2015 21:32:49 +0000 |
| Subject: | Re: RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-85141@lists.php.net to get a copy of this message | ||
On Tue, Mar 17, 2015 at 10:39 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:
> Hi!
> > Dmitry, the perf boost of this is awesome, but is it completely safe?
> > Won't a signal potentially overwrite a register variable here? Like on a
> > timeout, for example?
>
> The docs say (http://gcc.gnu.org/onlinedocs/gcc/Global-Reg-Vars.html):
>
> It is not safe to access the global register variables from signal
> handlers, or from more than one thread of control, because the system
> library routines may temporarily use the register for other things
> (unless you recompile them specially for the task at hand).
>
I don't see any problems to reuse the same registers outside executor.
>
> Also:
>
> It is not safe for one function that uses a global register variable to
> call another such function foo by way of a third function lose that is
> compiled without knowledge of this variable (i.e. in a different source
> file in which the variable isn't declared). This is because lose might
> save the register and put some other value there. For example, you can't
> expect a global register variable to be available in the
> comparison-function that you pass to qsort, since qsort might have put
> something else in that register. (If you are prepared to recompile qsort
> with the same global register variable, you can solve this problem.)
>
preserved registers are saved and restored as usually.
>
> So, I wonder how that would work with loadable modules and external
> libraries that could use PHP callbacks.
>
It works and I didn't see any problems yet :)
Thanks. Dmitry.
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>