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
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
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/
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/
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
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/
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
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
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
Hi Stas,
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
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
Hi Pierre,
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
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:
- Change the code.
- Remove the TSRMLS_* macros from the code in a subsequent commit
- Leave the no-op macros at an unused header for a few releases, for
the benefit of porting extensions / extensions targetting several versions.
Hi,
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:
- Change the code.
- Remove the TSRMLS_* macros from the code in a subsequent commit
- Leave the no-op macros at an unused header for a few releases, for
the benefit of porting extensions / extensions targetting several
versions.
- 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