FW: [PHP-DEV] Re: [PATCH] Tick functions (on C level) with state
| From: | Anatol Belski | Date: | Fri, 25 Sep 2015 08:17:32 +0000 |
| Subject: | FW: [PHP-DEV] Re: [PATCH] Tick functions (on C level) with state | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-88493@lists.php.net to get a copy of this message | ||
FYI the patch http://pastebin.com/wVymMAdZ , forwarding
as seems my mail filters put it into the internals folder while there was no internals in the
"to" list.
Regards
Anatol
-----Original Message-----
From: Anatol Belski [mailto:anatol.php@belski.net]
Sent: Thursday, September 24, 2015 6:49 PM
To: 'Andrey Hristov' <andrey.hristov@oracle.com>; 'Dmitry Stogov'
<dmitry@zend.com>
Cc: 'Anatol Belski' <ab@php.net>; 'Nikita Popov'
<nikita.ppv@gmail.com>
Subject: RE: [PHP-DEV] Re: [PATCH] Tick functions (on C level) with state
Andrey,
Thanks for the explanation. Please proceed the patch. The risks of it are quite low and the benefits
from the new MySQL features would outweigh in any case :)
Regards
Anatol
> -----Original Message-----
> From: Andrey Hristov [mailto:andrey.hristov@oracle.com]
> Sent: Thursday, September 24, 2015 5:32 PM
>
> Hi Dmitry, Anatol,
> this is the only thing that I would like to go into 7.0 . The code
> that will use the new ticks will be a mysqlnd plugin and will live in PECL.
> If the functionality is accepted by the community, then it will find
> its way into mysqli/mysqlnd. This way mysqli/mysqlnd will not be destabilized in 7.0 .
>
> Regarding the ticks, if no extension registers them, there is no
> overhead. The PECL extension, which will overload mysqlnd semantics,
> like mysqlnd-ms, mysqlnd-mc etc. do, will be declared experimental.
> When using experimental features things can be slower. A warning will be put in the
> documentation.
>
> All in all, this will help testing new features but in the common case
> it won't hurt anyone who is not using ticks. The patch doesn't make
> the performance of ticks worse, it allows flexibility :)
>
> I am sure there is a better way to do async, however adding it is not
> as simple as this patch.
>
>
> Best,
> Andrey