Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Native TLS »

[RFC] Native TLS

php.internals

Anatol Belski

11 years ago
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

Joe Watkins

11 years ago
On Thu, 2014-11-27 at 16:54 +0100, 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 > >
Afternoon Anatol, w00t That is all :) Cheers Joe

Andrew Faulds

11 years ago
> On 27 Nov 2014, at 15:54, Anatol Belski <anatol.php@belski.net> wrote: > 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/

Andrew Faulds

11 years ago
> On 27 Nov 2014, at 16:44, Andrea Faulds <ajf@ajf.me> wrote: > > >> On 27 Nov 2014, at 15:54, Anatol Belski <anatol.php@belski.net> wrote: >> 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? :)
Treaded? Dreaded. Sorry.
-- Andrea Faulds http://ajf.me/

Joe Watkins

11 years ago
On Thu, 2014-11-27 at 16:44 +0000, Andrea Faulds wrote:
> > On 27 Nov 2014, at 16:44, Andrea Faulds <ajf@ajf.me> wrote: > > > > > >> On 27 Nov 2014, at 15:54, Anatol Belski <anatol.php@belski.net> wrote: > >> 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? :) > > Treaded? Dreaded. Sorry. > > -- > Andrea Faulds > http://ajf.me/ > > > > >
Afternoon Andrea, Yes, they can be removed, as it mentions in RFC. Cheers Joe

Andrew Faulds

11 years ago
> On 27 Nov 2014, at 17:01, Joe Watkins <pthreads@pthreads.org> wrote: > > On Thu, 2014-11-27 at 16:44 +0000, Andrea Faulds wrote: >>> On 27 Nov 2014, at 16:44, Andrea Faulds <ajf@ajf.me> wrote: >>> >>> Hey! >>> >>> Would this mean we could eventually get rid of the treaded TSRMLS_CC/DC altogether? :) >> >> Treaded? Dreaded. Sorry. > > 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/

Anatol Belski

11 years ago
On Thu, November 27, 2014 18:03, Andrea Faulds wrote:
>
>> On 27 Nov 2014, at 17:01, Joe Watkins <pthreads@pthreads.org> wrote: >> >> >> On Thu, 2014-11-27 at 16:44 +0000, Andrea Faulds wrote: >> >>>> On 27 Nov 2014, at 16:44, Andrea Faulds <ajf@ajf.me> wrote: >>>> >>>> >>>> Hey! >>>> >>>> >>>> Would this mean we could eventually get rid of the treaded >>>> TSRMLS_CC/DC >>>> altogether? :) >>> >>> Treaded? Dreaded. Sorry. >>> >> >> 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. >
Yeah, so is it, all the TSRMLS_* stuff would go away. Cheers Anatol

Keisial

11 years ago
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

Stas Malyshev

11 years ago
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

Anatol Belski

11 years ago
Hi Stas, On Sat, November 29, 2014 00:05, Stanislav Malyshev 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. > > 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

Pierre Joye

11 years ago
hi Anatol! On Fri, Nov 28, 2014 at 2:54 AM, Anatol Belski <anatol.php@belski.net> 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.
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

Anatol Belski

11 years ago
Hi Pierre, On Wed, December 3, 2014 02:36, Pierre Joye wrote:
> hi Anatol! > > On Fri, Nov 28, 2014 at 2:54 AM, Anatol Belski <anatol.php@belski.net> > 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. > > 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

Keisial

11 years ago
On 03/12/14 10:22, Anatol Belski wrote:
> 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.

Anatol Belski

11 years ago
Hi, On Mon, December 8, 2014 20:42, Ángel González wrote:
> On 03/12/14 10:22, Anatol Belski wrote: > >> 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. >
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