Re: [PHP-DEV] [RFC] Move pecl_sync to core
On 9/29/2014 8:06 PM, guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. Cheers, As the original author of this extension, I only have a few caveats to point out: 1) It has a dependency on POSIX semaphores on non-Windows platforms. From what I understand, not all platforms have support for POSIX semaphores. I feel that if this is going to be moved to core that someone with a deeper familiarity of POSIX support across OSes take a look at what platforms won't be supported and whether or not anyone actually cares about the unsupported environments. Every modern distro I've tried has support. 2) Another consideration is the use of the code in common shared hosting environments. If two objects share the same name but are used differently in two different applications on the same machine, it will result in undefined behavior. The object won't crash but it won't necessarily behave the way it is intended to behave. This is true of any synchronization object, but is something to be aware of as a possible issue since the code does expose OS level synchronization objects to web applications. Much of this issue is minimized by making the different types of objects (Mutex, Semaphore, etc.) have unique prefixes but it doesn't mean there can't/won't be any conflicts. 3) Creating a POSIX named object as 'root' and then attempting to open it as another user fails with an obscure permission denied error. This can happen if the object is initially created by a cron job that's run as root and then a web application attempts to open the same object later on. The userland functions posix_setuid()/posix_seteuid() and/or posix_setgid() can be used to counter the effect. (Whether or not PHP based cron jobs should run as the root user is a different discussion.) 4) The naming scheme of the various named objects should be examined to make sure they conform to any existing naming conventions. For example, the name hello becomes /Sync_Mutex_hello_0 in a POSIX named mutex object while the name is left as hello in a Windows named mutex object. Just a few thoughts. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On 30 September 2014 04:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. What are the actual benefits of this being included in core? The RFC doesn't really list any. Also, there was a discussion in June (started by Julien) about refactoring PHPs IO layer, where many people expressed a wish to have something libuv based in core, this comes with cross-platform semaphors and mutexes as well as a TON of other awesome goodies. If anything, this is what I would prefer in core. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On Tue, Sep 30, 2014 at 8:58 AM, Leigh lei...@gmail.com wrote: On 30 September 2014 04:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. What are the actual benefits of this being included in core? The RFC doesn't really list any. Also, there was a discussion in June (started by Julien) about refactoring PHPs IO layer, where many people expressed a wish to have something libuv based in core, this comes with cross-platform semaphors and mutexes as well as a TON of other awesome goodies. If anything, this is what I would prefer in core. Why would you use PHP for such low level concepts ? I don't think this is useful, better write C for the target platform I think. And this extension is very young and may be very buggy as it plays with lots of crossplatform-hell concepts. Why would we support it in Core ? Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On Tue, 30 Sep 2014, Remi Collet wrote: Le 30/09/2014 05:06, guilhermebla...@gmail.com a écrit : Here is a new RFC: https://wiki.php.net/rfc/sync Isn't this extension a bit young to join php core ? I'd say both that, and that the RFC is *very* minimal. THere is no rationale why this should be part of the code for example. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: What happened to the 5.6.1 release?
On Mon, Sep 29, 2014 at 9:31 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I wonder if one could replace that release server with a simple vagrant setup or similar so the RM can actually create release archives on his own. I've always packaged 5.4 on my local machine, but it may have a downside of using different bison/automake/etc. version and produce a release that has different compatibility matrix than officially announced. So This is the same to me. AFAIR, we patched the README.RELEASE_PROCESS to explicitely list the requirements, particulary the bison ones, for building on local envs. I've always built my releases on my local machine, with very accurate version of autoconf and bison. Julien.Pauli -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
This needs a Why section. Why is this good for PHP? Why will a significant percentage of users be interested in this? Why is it necessary? This feel pretty niche to me. -Sara On Sep 30, 2014, at 4:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. Cheers, -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
From: Andrey Andreev n...@devilix.net Sent: Sep 29, 2014 3:01 PM To: Sharon Levy sle...@pipeline.com Cc: Zeev Suraski z...@zend.com, Derick Rethans der...@php.net, Andrea Faulds a...@ajf.me, PHP internals internals@lists.php.net Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs? On Tue, Sep 30, 2014 at 12:28 AM, Sharon Levy sle...@pipeline.com wrote: I think in all fairness, users should be required to learn C and pass a test demonstrating basic knowledge of PHP's internals in order to acquire voting privileges. So, in order to vote, users should become (capable of being) core contributors? :) How does that change anything? Cheers, Andrey. ... the important truths, that knolege is power, that knolege is safety, and that knolege is happiness. -- Thomas Jefferson If more users were educated about PHP's internals, then there could be more substantive discussions between Userland and core contributors, including better ideas originating from Userland. More users might even consider becoming core contributors. It would change the status quo.
Re: [PHP-DEV] [RFC] Move pecl_sync to core
Fix the title? :) Is it for sync or pecl_http? Someone already fixed that. Isn't this extension a bit young to join php core ? I agree. However, there's no equivalent existing support in PHP atm. Also, any new functionality introduced to PHP would always be new, young and caring maturity. What are the actual benefits of this being included in core? The RFC doesn't really list any. I updated the RFC to include some rationale around it. Also, there was a discussion in June (started by Julien) about refactoring PHPs IO layer, where many people expressed a wish to have something libuv based in core, this comes with cross-platform semaphors and mutexes as well as a TON of other awesome goodies. If anything, this is what I would prefer in core. I would love that, because it would make this RFC obsolete IF the low level API also gets exposed to userland. But if I/O gets refactored we have 2 alternatives: - Locking is built-in concurrency intensive places, such as file creation, writing, cache inclusion, etc. - Low level API gets exposed to consumers, then any extension or userland code could benefit Why would you use PHP for such low level concepts ? I think I was able to answer that through the rationale section exposing an example on RFC. Please reply back if not. Why would we support it in Core? Why is this good for PHP? PHP doesn't offer an easy cross-platform way to implement locking. All you can do is through flock emulating Mutexes and Semaphores, but even this is not cross-platform; for example, Windows does not support blocking until it acquires the lock. Why will a significant percentage of users be interested in this? Why is it necessary? Not a significant percentage would use it at userland level, I agree. However, low level libraries could benefit that would later benefit many other projects and people. I, for example, would consider to add locking support inside of Doctrine\Cache, which would benefit Zend, Symfony, Drupal, CMSs and many other projects that rely on this low level abstraction API. But currently, I'm unable to do it since there's no PHP support and also because we avoid enforcing the necessity of PECL extensions to get code up and running. PHP is not a toy language anymore and more robust functionality is severely needed to the language move forward. I consider Locking is one of the missing pieces to the language, but the world is not made of Guilherme Blanco's... =P PS: I'll answer Thomas' email later. On Tue, Sep 30, 2014 at 1:27 PM, Sara Golemon p...@golemon.com wrote: This needs a Why section. Why is this good for PHP? Why will a significant percentage of users be interested in this? Why is it necessary? This feel pretty niche to me. -Sara On Sep 30, 2014, at 4:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. Cheers, -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 30, 2014 at 10:31 PM, Sharon Levy iam4webw...@hotmail.com wrote: From: Andrey Andreev n...@devilix.net Sent: Sep 29, 2014 3:01 PM To: Sharon Levy sle...@pipeline.com Cc: Zeev Suraski z...@zend.com, Derick Rethans der...@php.net, Andrea Faulds a...@ajf.me, PHP internals internals@lists.php.net Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs? On Tue, Sep 30, 2014 at 12:28 AM, Sharon Levy sle...@pipeline.com wrote: I think in all fairness, users should be required to learn C and pass a test demonstrating basic knowledge of PHP's internals in order to acquire voting privileges. So, in order to vote, users should become (capable of being) core contributors? :) How does that change anything? Cheers, Andrey. ... the important truths, that knolege is power, that knolege is safety, and that knolege is happiness. -- Thomas Jefferson If more users were educated about PHP's internals, then there could be more substantive discussions between Userland and core contributors, including better ideas originating from Userland. More users might even consider becoming core contributors. It would change the status quo. Well, let's see ... what is the current status quo? Currently, all voters have VCS accounts, meaning that they already are at least one of: a) C code contributors b) documentation contributors c) contributing to the php.net website or something else but similar It is written somewhere that maintainers of popular userland frameworks and tools _could_ get voting privileges, but the voters from this group are voters because they already have VCS accounts for other purposes. It is otherwise undefined how that happens - this is as close as you can get to the meaning of status quo as far as userland people are concerned. What this basically means is that currently you ARE required to either know C and PHP's internals, or to take care of all the not really fun (for a programmer) stuff that surrounds it. It that hasn't encouraged more people to contribute, how would taking away non-C-contributors' votes be an encouragement? If I was a php-doc contributor, that would be you showing me the middle finger, not encouragement. Sure, it would change the status quo, but for the worse. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On 30 Sep 2014, at 20:56, guilhermebla...@gmail.com wrote: Isn't this extension a bit young to join php core ? I agree. However, there's no equivalent existing support in PHP atm. That, in itself, is not necessarily a justification. Unless an awful lot of PHP users need this, it shouldn’t be in core. Also, any new functionality introduced to PHP would always be new, young and caring maturity. What does that even mean? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Tue, Sep 30, 2014 at 12:59 PM, Andrey Andreev n...@devilix.net wrote: On Tue, Sep 30, 2014 at 10:31 PM, Sharon Levy iam4webw...@hotmail.com wrote: From: Andrey Andreev n...@devilix.net Sent: Sep 29, 2014 3:01 PM To: Sharon Levy sle...@pipeline.com Cc: Zeev Suraski z...@zend.com, Derick Rethans der...@php.net, Andrea Faulds a...@ajf.me, PHP internals internals@lists.php.net Subject: Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs? On Tue, Sep 30, 2014 at 12:28 AM, Sharon Levy sle...@pipeline.com wrote: I think in all fairness, users should be required to learn C and pass a test demonstrating basic knowledge of PHP's internals in order to acquire voting privileges. So, in order to vote, users should become (capable of being) core contributors? :) How does that change anything? Cheers, Andrey. ... the important truths, that knolege is power, that knolege is safety, and that knolege is happiness. -- Thomas Jefferson If more users were educated about PHP's internals, then there could be more substantive discussions between Userland and core contributors, including better ideas originating from Userland. More users might even consider becoming core contributors. It would change the status quo. Well, let's see ... what is the current status quo? Currently, all voters have VCS accounts, meaning that they already are at least one of: a) C code contributors b) documentation contributors c) contributing to the php.net website or something else but similar It is written somewhere that maintainers of popular userland frameworks and tools _could_ get voting privileges, but the voters from this group are voters because they already have VCS accounts for other purposes. It is otherwise undefined how that happens - this is as close as you can get to the meaning of status quo as far as userland people are concerned. What this basically means is that currently you ARE required to either know C and PHP's internals, or to take care of all the not really fun (for a programmer) stuff that surrounds it. It that hasn't encouraged more people to contribute, how would taking away non-C-contributors' votes be an encouragement? If I was a php-doc contributor, that would be you showing me the middle finger, not encouragement. Sure, it would change the status quo, but for the worse. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php +1 I agree completely. This discussion has raised another issue though that I think merits further consideration: What standards do we use to give VCS accounts-- or karma, for that matter. As many have pointed out already, we don't currently have a consistent, quantifiable standard for either of these. This can lead to some people getting VCS creds who may not have actually done anything to merit that, at least according to some people here. Likewise, there is no specific standard for giving people karma; just a vague understanding that those who contribute enough will eventually maybe get it. If you want to tackle the problem of new people not being motivated to contribute, that's probably the #1 (or maybe #2, behind the steep learning curve) reason why there's an absense of fresh faces submitting code. As someone who has been a project manager over the years, I can tell you that nothing motivates people more than giving them set goals to achieve and rewards for achieving them. For example, if you contribute x number of patches, resolve y number of bugs, z number of pull requests, etc, you'll qualify for basic karma. That would provide a quantifiable incentive and I guarantee you we'll get people who will start contributing in order to meet that goal and get that feather in their cap. Right now, most people don't even know who grants karma, how to request it, or when it's appropriate to request it. The current, Just contribute steadily over time and we'll see message may have the advantage of giving us greater discretion, but it does nothing to motivate people to participate. As far as VCS access goes, having specific metrics like that probably wouldn't be feasible since it's much more of a case-by-case basis sorta thing. We could establish some general guidelines, though. To prevent VCS accounts from being given out frivolously, as some have complained, I suggest we treat each qualifying VCS request as an RFC. The person (sponsor?) who thinks they should be added adds an RFC, outlining the person's experience and why s/he qualifies for VCS access. Then we vote and simple majority wins. I think it would be beneficial for us to draft an RFC that establishes these changes. That way, we can address the concerns raised by those who believe that VCS-- and, with it, voting rights-- is being given out too easily, while also maintaining the inclusiveness of the current voting system. It
Re: [PHP-DEV] [RFC] Move pecl_sync to core
What does that even mean? It means that any new functionality that gets into core could be considered young. Like when PHAR got introduced, it was a young extension. Same for PDO, same for FileInfo... What I'm trying to highlight is that being a recently coded extension or not, it's not a good argument to say join/no join. On Tue, Sep 30, 2014 at 4:05 PM, Andrea Faulds a...@ajf.me wrote: On 30 Sep 2014, at 20:56, guilhermebla...@gmail.com wrote: Isn't this extension a bit young to join php core ? I agree. However, there's no equivalent existing support in PHP atm. That, in itself, is not necessarily a justification. Unless an awful lot of PHP users need this, it shouldn’t be in core. Also, any new functionality introduced to PHP would always be new, young and caring maturity. What does that even mean? -- Andrea Faulds http://ajf.me/ -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On 30 September 2014 20:31, Sharon Levy iam4webw...@hotmail.com wrote: If more users were educated about PHP's internals, then there could be more substantive discussions between Userland and core contributors, including better ideas originating from Userland. More users might even consider becoming core contributors. It would change the status quo. It's up to you to educate yourself. You don't have to be amazing, you just have to be willing. Uncomfortable with C? Get out of your comfort zone. If you've done PHP for more than a couple of years you have more than enough background to kick start yourself. Please don't take this as some condescending statement, take a few hours, dive in, change something small, get it working and get a sense of achievement from it. Come and join that chat on IRC or Stack Overflow, there are numerous people who _want to help_ you get better at this. Being even slightly familiar with the internals is a _huge_ advantage when it comes to discussing and voting on core language changes. I'm sure you can appreciate the difference between a vote for ooh shiny, do want and crap this will break everything. Makes sense for the people voting to have some sort of understanding beyond the superficial right? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
2014-09-30 21:59 GMT+02:00 Andrey Andreev n...@devilix.net: Well, let's see ... what is the current status quo? Currently, all voters have VCS accounts, meaning that they already are at least one of: a) C code contributors b) documentation contributors c) contributing to the php.net website or something else but similar And anyone with a wiki account can vote too, meaning everyone who wrote an RFC can in theory vote on anything, take for example fabpot, who does not have an VCS account but can vote still because he have a wiki account, which is outside that boundary. regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c
Hi, I took a quick look over the patch. I didn't get why it's named native_tls now, because it doesn't use __thread variables anymore. Actually, now the patch get rid of additional TSRMLS_ arguments, but performs near the same thing as TSRMLS_FETCH() on each module global access. It leads to huge slowdown. bench.php. non-zts: 1.222 sec zts: 1.362 sec native_tls: 1.785 sec I think, the patch makes no sense in this state. It looks like on Windows we can't use __declspec(thread) in DLLs loaded using LoadLibray() at all, so we won't ale to build mod_php for Apache or use __declspec(thread) for module globals of extensions build as DLL On Linux it must be possible, but it depends on TLS model (gcc -ftls-model=...). global-dynamic model must work in all cases, but I'm not sure about performance, because it'll lead to additional function call for each __thread variable access (may be I'm wrong). Better models (like initial-exec) have some limitations. I don't have enough experience to say, if they could work for us. Thanks. Dmitry. On Mon, Sep 29, 2014 at 10:54 AM, Dmitry Stogov dmi...@zend.com wrote: Hi Anatol. I'll take a look on Tuesday or Wednesday. Thanks. Dmitry. On Sat, Sep 27, 2014 at 12:59 AM, Anatol Belski anatol@belski.net wrote: Hi Dmitry, On Mon, September 22, 2014 08:43, Dmitry Stogov wrote: Hi Anatol, I didn't completely get your ideas, but if tsrm_ls_cache can't be exported on Windows directly, can we have a copy of tsrm_ls_cache in each DLL/EXE and initialize it once? Thanks. Dmitry. Joe and me was working on this and there is a worky version now. Generally it suffers from some issues already present in master, but in all things together it's a worky crossplatform approach. Please look up the native-tls branch. For the current variant I used the idea from the original RFC, but removed exporting the TSRM cache through a __thread variable as it's not portable. I've also removed the offset logic from the RFC patch, as that brought additional hard to find bugs especially into the current unstable version. I don't think it's necessary to copy the arbitrary globals structs in every ext, further more i think it's not easy possible without some big overhead. However even with the current native-tls branch I'm able to run wordpress, symfony, ab -c 8 -n 2048 pass also with multiple calls. Still, some Apache bugs are already reported against master, I also repro some others, mostly arbitrary shutdown crashes in Apache (so TS version). So as they're in master, they're for sure in native-tls. PHP happens to always have used TLS, however the pointer was passed directly to the functions. In TSRM.c, that's tsrm_tls_get/tsrm_tls_set. Now, a function wrapper is used to fetch the TLS cache directly in the TSRMG macro. This makes the whole slowlier, but allows to get rid of the TSRMLS_* macros. The big question is to optimize the function call to speedup the whole. Maybe one can speedup it saving a tsrm ls cache pointer locally per extension or code area. ATM we're checking the functional part, then one can proceed further with removing the TSRMLS_* macros. Any speedup or improvement thoughts are welcome. Possible directions of the further work after known bugs are fixed (in master or in native-tls), some are mutually exclusive - reimplement the offset logic instead of arrays for the globals structs - share the tsrm cache pointer globally to some scope, like extension or sapi - remove the linked lists logic and use TLS explicitly - improve locking Thanks Anatol
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On 30 September 2014 23:05, Kalle Sommer Nielsen ka...@php.net wrote: And anyone with a wiki account can vote too, meaning everyone who wrote an RFC can in theory vote on anything, take for example fabpot, who does not have an VCS account but can vote still because he have a wiki account, which is outside that boundary. Sorry have to contest this one. I could not vote with purely wiki RFC karma. I could create RFCs but could not vote without an upgrade. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is it fair that people with no karma can vote on RFCs?
On Wed, Oct 1, 2014 at 1:17 AM, Leigh lei...@gmail.com wrote: On 30 September 2014 23:05, Kalle Sommer Nielsen ka...@php.net wrote: And anyone with a wiki account can vote too, meaning everyone who wrote an RFC can in theory vote on anything, take for example fabpot, who does not have an VCS account but can vote still because he have a wiki account, which is outside that boundary. Sorry have to contest this one. I could not vote with purely wiki RFC karma. I could create RFCs but could not vote without an upgrade. I can confirm that. I only have a wiki.php.net account, I've written RFCs and I can't vote. And that's how it should be IMO. Wiki accounts can be given way more easily, anybody can request one on the grounds of just having some idea. There has to be _some_ barrier after all. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Remove generated lexers from git?
On Tue, Aug 26, 2014 at 9:55 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! Currently our git repo contains files like zend_language_scanner.c, zend_ini_scanner.c, etc which are files generated by re2c. Historically these files have been included because re2c was not readily available on many platforms. In the thread on bison 3 compatibility [1] there was some discussion as to whether this limitation still applies. Quoting Adam Harvey: +1. I don't think re2c is that onerous a requirement anyway, for the most part: it's available through apt-get, brew, yum, and probably most other packaging systems. Given the amount of other things a developer has to install to build php-src from git, re2c is hardly going to break the camel's back. So, I'd like to bring this up again. Are there any objections to removing generated lexer files from the repo? If not, does it suffice to just git rm them and add them to .gitignore, or are other changes required? Nikita [1]: http://markmail.org/message/x3p7ltekzws6ywhw I'd like to bring this up again. It seems the thread got side-tracked with unrelated discussion (about vm_execute.h) and I didn't get any answers to the original question. Case in point: The current zend_language_scanner.c has been generated by Andrea, who uses a different re2c version from everybody else (0.13.6 instead of 0.13.5). This means that if I do some tiny change to zend_language_scanner.l I immediately get a 3000 line diff. So we just end up changing this file back and forth depending on the algorithm used by different versions. Nikita
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in ZTS: Zend/zend.c
Hi Dmtry, thanks for taking a look at this. On Wed, October 1, 2014 00:09, Dmitry Stogov wrote: Hi, I took a quick look over the patch. I didn't get why it's named native_tls now, because it doesn't use __thread variables anymore. I was wondering myself but now I see (intentionally taking the 5.2 source) http://lxr.php.net/xref/PHP_5_2/TSRM/TSRM.c#282 http://lxr.php.net/xref/PHP_5_2/TSRM/TSRM.c#329 We already use TLS :) It took quite some time to understand this. Actually, now the patch get rid of additional TSRMLS_ arguments, but performs near the same thing as TSRMLS_FETCH() on each module global access. It leads to huge slowdown. bench.php. non-zts: 1.222 sec zts: 1.362 sec native_tls: 1.785 sec I think, the patch makes no sense in this state. Absolutely, this state is just to show we can drop the TSRMLS_* things without hurting the functional part. At least I'm glad you have noticed no regression on the functionality, but just the slowdown. It looks like on Windows we can't use __declspec(thread) in DLLs loaded using LoadLibray() at all, so we won't ale to build mod_php for Apache or use __declspec(thread) for module globals of extensions build as DLL On Linux it must be possible, but it depends on TLS model (gcc -ftls-model=...). global-dynamic model must work in all cases, but I'm not sure about performance, because it'll lead to additional function call for each __thread variable access (may be I'm wrong). Better models (like initial-exec) have some limitations. I don't have enough experience to say, if they could work for us. With the linux part - yeah, the gcc linker does the great magic which makes __thread variables work between shared objects. The function call is needed specifically because on Windows it is not possible to do __declspec(dllexport) __declspec(thread). With __dllspec(thread) unusable when explicitly loaded - not true since Vista anymore. Please read here http://msdn.microsoft.com/en-us/library/windows/desktop/ms684175%28v=vs.85%29.aspx Windows Server 2003 and Windows XP: The Visual C++ compiler supports a syntax that enables you to declare thread-local variables: _declspec(thread). If you use this syntax in a DLL, you will not be able to load the DLL explicitly using LoadLibrary on versions of Windows prior to Windows Vista. If your DLL will be loaded explicitly, you must use the thread local storage functions instead of _declspec(thread). For an example, see Using Thread Local Storage in a Dynamic Link Library. So this is not an issue as we won't support XP in PHP7 anyway. But the issue is that it cannot export a thread specific variable, but it can perfectly gain the access to it through an explicit tls storage query. MSDN provides also a snippet on how it works http://msdn.microsoft.com/en-us/library/windows/desktop/ms686997%28v=vs.85%29.aspx While investigating on it, i've added one more DLL which loads through LoadLibrary and it worked the same way as the DLL linked implicitly using a .lib file. Let me know if you'd like to look at my investigation code on this. Just to sumarize: - TLS is used all the way since at least 5.2 - the portable way to share the tls storage is by accessing it through tsrm_tls_get/tsrm_tls_set macros - function calls slow down everything That is why I mean - the patch is functionally doing the same what the mainstream does, but allows to remove the TSRMLS_* macros. Btw. the thread keys get allocated by Apache already. Maybe we have to care about that in some other SAPI but I'm not sure there is another one except mpm_worker/mpm_winnt which can exhaust all the TS potential. In Apache it's spread over several sources, however here is the essential part http://svn.apache.org/viewvc/apr/apr/trunk/threadproc/win32/threadpriv.c?view=markup My current idea on how to speed up it - the __thread or __declspec(thread) variables can be used and are both portable within the same binary unit (say .so, .dll, .exe, etc.). Once we have a resource pointer, it can be cached in a local variable. In some header, it would be declared like TSRM_TLS extern void *tsrm_cache; And in one .c file it would be properly defined. The header would make it accessible from all the .c files in the same binary unit (all object files linked together). Of course, this variable has to be updated once per thread before any globals could be read. What is needed is to lookup the correct places to update that variable. Such a variable will have unfortunately to be defined in every so/dll/exe and then updated accordingly. But getting the tsrm cache per function call will still work. Maybe something comes in your mind where such correct places should be? zend_startup() and zend_activate()? When it's worky, it might even solve some perf issue also with Linux, if I understood it correctly. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Remove alternative PHP tags
On 24/09/2014 20:13, Nikita Popov wrote: The vote for removal of alternative PHP opening/closing tags in PHP 7 is now open: https://wiki.php.net/rfc/remove_alternative_php_tags#vote Hi! We've talked about this RFC with several other members of AFUP (French UG), and we pretty much all agree that PHP 7 is the right time to remove these alternative tags. This might/will cause BC-breaks for a few scripts and applications, but it seems acceptable, as: * Those alternative tags are not used that much (so, not too many applications should break) * Detecting and fixing these breaks should not be too hard and can, at least in part, be automated. -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
