# [RFC] Native TLS - Thread: https://externals.io/message/79236 - Original archive: https://news-web.php.net/php.internals/79236 - Started by Anatol Belski on 2014-11-27T15:54:01+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #79236 — Anatol Belski — 2014-11-27T15:54:01+00:00 URL: https://externals.io/message/79236#79236 Hi, this is a long spoken topic which is now embodied in https://wiki.php.net/rfc/native-tls . A preliminary implementation is there as well, thus we can discuss it. Regards Anatol --- ## #79237 — Joe Watkins — 2014-11-27T16:09:02+00:00 URL: https://externals.io/message/79236#79237 · In reply to: #79236 > Hi, > > this is a long spoken topic which is now embodied in > https://wiki.php.net/rfc/native-tls . A preliminary implementation is > there as well, thus we can discuss it. > > Regards > > Anatol > > Afternoon Anatol, w00t That is all :) Cheers Joe --- ## #79238 — Andrea Faulds — 2014-11-27T16:44:26+00:00 URL: https://externals.io/message/79236#79238 · In reply to: #79236 > > this is a long spoken topic which is now embodied in > https://wiki.php.net/rfc/native-tls . A preliminary implementation is > there as well, thus we can discuss it. Hey! Would this mean we could eventually get rid of the treaded TSRMLS_CC/DC altogether? :) -- Andrea Faulds http://ajf.me/ --- ## #79239 — Andrea Faulds — 2014-11-27T16:44:56+00:00 URL: https://externals.io/message/79236#79239 · In reply to: #79238 > > > > > […] > > Hey! > > Would this mean we could eventually get rid of the treaded TSRMLS_CC/DC altogether? :) Treaded? Dreaded. Sorry. -- Andrea Faulds http://ajf.me/ --- ## #79240 — Joe Watkins — 2014-11-27T17:01:51+00:00 URL: https://externals.io/message/79236#79240 · In reply to: #79239 > > […] > > Treaded? Dreaded. Sorry. > > -- > Andrea Faulds > http://ajf.me/ > > > > > Afternoon Andrea, Yes, they can be removed, as it mentions in RFC. Cheers Joe --- ## #79241 — Andrea Faulds — 2014-11-27T17:03:57+00:00 URL: https://externals.io/message/79236#79241 · In reply to: #79240 > > > > > […] > > Afternoon Andrea, > > Yes, they can be removed, as it mentions in RFC. Argh, I should’ve read the RFC more carefully. Well, I’m all for this, if only to stop people accidentally breaking the thread-safe builds. +1 -- Andrea Faulds http://ajf.me/ --- ## #79248 — keisial@gmail.com — 2014-11-27T20:01:37+00:00 URL: https://externals.io/message/79236#79248 · In reply to: #79236 Anatol Belski wrote: > Hi, > > this is a long spoken topic which is now embodied in > https://wiki.php.net/rfc/native-tls . A preliminary implementation is > there as well, thus we can discuss it. > > Regards > > Anatol Great! I remember myself already wondering about that years ago. +1 --- ## #79250 — Anatol Belski — 2014-11-27T20:13:07+00:00 URL: https://externals.io/message/79236#79250 · In reply to: #79241 > > > […] > > Argh, I should’ve read the RFC more carefully. Well, I’m all for this, if > only to stop people accidentally breaking the thread-safe builds. > Yeah, so is it, all the TSRMLS_* stuff would go away. Cheers Anatol --- ## #79301 — Stanislav Malyshev — 2014-11-28T23:05:28+00:00 URL: https://externals.io/message/79236#79301 · In reply to: #79236 Hi! > this is a long spoken topic which is now embodied in > https://wiki.php.net/rfc/native-tls . A preliminary implementation is > there as well, thus we can discuss it. This sounds great! \o/ I understand there's no practical performance impact? If so, code simplification looks like a real win. -- Stas Malyshev smalyshev@gmail.com --- ## #79311 — Anatol Belski — 2014-11-29T18:14:33+00:00 URL: https://externals.io/message/79236#79311 · In reply to: #79301 Hi Stas, > Hi! > > > > […] > > This sounds great! \o/ > I understand there's no practical performance impact? If so, code > simplification looks like a real win. > yep, the tests show it's at least as fast as the mainstream. The patch from the first RFC was replacing the array access with offset logic. Unfortunately I had to revert it as it was playing not good with the current master, so I just separated it from the approach. I see the "index vs offset" as something one can build upon the current RFC. Regards Anatol --- ## #79391 — Pierre Joye — 2014-12-03T01:36:39+00:00 URL: https://externals.io/message/79236#79391 · In reply to: #79236 hi Anatol! > Hi, > > this is a long spoken topic which is now embodied in > https://wiki.php.net/rfc/native-tls . A preliminary implementation is > there as well, thus we can discuss it. Awesome work as usual! As other mentioned, we should get rid of the TSRM_* macros for declaratons/calls. Having them as placebo for the sake of having them and reduce the amount of changes brought by this patch make little sense to me. Master requires now a lot of changes anyway, we may as well just kill that while being at it, easy move. Maybe add a vote option to either keep the placebo (less code change) or remove it (easier in the long term, no more TS build break, or fewer). Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #79392 — Anatol Belski — 2014-12-03T09:22:54+00:00 URL: https://externals.io/message/79236#79392 · In reply to: #79391 Hi Pierre, > hi Anatol! > > On Fri, Nov 28, 2014 at 2:54 AM, Anatol Belski > wrote: > > > […] > > Awesome work as usual! > > > > As other mentioned, we should get rid of the TSRM_* macros for > declaratons/calls. Having them as placebo for the sake of having them and > reduce the amount of changes brought by this patch make little sense to > me. Master requires now a lot of changes anyway, we may as well just kill > that while being at it, easy move. Maybe add a vote option to either keep > the placebo (less code change) or remove it (easier in the long term, no > more TS build break, or fewer). > I meant that as well, to the time it's merged all the TSRMLS_* thingies should be removed. I kept them only while developed and now for the RFC so the diff shows the only change done, otherwise it would sink in the unrelevant stuff. Therefore I'd rather stay by the yes/no choice as removing TSRMLS_* is the essential part of the RFC - so better at once then :) As otherwise one can sure find some factor to defer the actual change, but the change is the actual goal. Regards Anatol --- ## #79479 — keisial@gmail.com — 2014-12-08T19:42:44+00:00 URL: https://externals.io/message/79236#79479 · In reply to: #79392 > I meant that as well, to the time it's merged all the TSRMLS_* thingies > should be removed. I kept them only while developed and now for the RFC so > the diff shows the only change done, otherwise it would sink in the > unrelevant stuff. > > Therefore I'd rather stay by the yes/no choice as removing TSRMLS_* is the > essential part of the RFC - so better at once then :) As otherwise one can > sure find some factor to defer the actual change, but the change is the > actual goal. > > Regards > > Anatol It seems quite clear to me: 1. Change the code. 2. Remove the TSRMLS_* macros from the code in a subsequent commit 3. Leave the no-op macros at an unused header for a few releases, for the benefit of porting extensions / extensions targetting several versions. --- ## #79505 — Anatol Belski — 2014-12-09T15:41:12+00:00 URL: https://externals.io/message/79236#79505 · In reply to: #79479 Hi, > > > > […] > > It seems quite clear to me: > 1. Change the code. > 2. Remove the TSRMLS_* macros from the code in a subsequent commit > 3. Leave the no-op macros at an unused header for a few releases, for > the benefit of porting extensions / extensions targetting several > versions. > 1. and 2. - yes, to 3. - won't help much probably as the core function signatures will be changed. And the compatibility macros are probably not doable as most of the functions keep their names. Sometimes it could help, but for a PECL ext - as the core function calls have to be corrected, so the extension own ones can be done as well. Regards Anatol