No. Php if we talk about php with all its extensions is not threadsafe
at
all. Many of the extensions allocate static data and inherently
non-thread-safe.
PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
some extensions might not be thread safe, but basically all
On Dec 16, 2010, at 12:28 AM, jvlad wrote:
No. Php if we talk about php with all its extensions is not threadsafe
at
all. Many of the extensions allocate static data and inherently
non-thread-safe.
PHP is, if compiled with ZTS/TSRM, thread-safe. Some libraries used by
some extensions
Hi!
An example of non-thread safe is gettext it relies on the locale which is per
process and not per-thread.
PHP itself at the core is thread safe. As Johannes said most common modules are
too.
ICU btw has some global stuff too. It's actually worse as it has one
global which is set
Scott MacVicar wrote in message:
Do you think any locking function is implemented in openssl php
extension?
In PHP a SSL_CTX is per thread and is not shared across other threads so
it isn't an issue. We don't need to implement any openssl locking
functions.
It does not matter
The PHP development team would like to announce the immediate
availability of PHP 5.2.16. This release marks the end of support for
PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.
This release focuses on addressing a regression in open_basedir
implementation introduced in
hi,
The more I look at this option the more I think it is confusing. I'm
not sure the gain is worth this confusion either. However I would
prefer to bring back a proposal we had a couple of years ago, to
totally disable post data. When disabled, the POST data will be
totally ignored, no matter if
On Thu, Dec 16, 2010 at 1:32 PM, Pierre Joye pierre@gmail.com wrote:
hi,
The more I look at this option the more I think it is confusing. I'm
not sure the gain is worth this confusion either. However I would
prefer to bring back a proposal we had a couple of years ago, to
totally
hi,
On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs i...@tyrael.hu wrote:
So currently we didn't talk about security measures, but performance gains:
If somebody wants to write a script, which handles big file uploads, but
only writes it to somewhere (to file, or another stream), then
On Thu, Dec 16, 2010 at 1:47 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Thu, Dec 16, 2010 at 1:42 PM, Ferenc Kovacs i...@tyrael.hu wrote:
So currently we didn't talk about security measures, but performance
gains:
If somebody wants to write a script, which handles big file
On Thu, 16 Dec 2010 12:47:43 -, Pierre Joye pierre@gmail.com
wrote:
As I said in IRC, I see no value in having an option that disables
accessing POST data completely (i.e. the behavior of
enable_post_data_reading=Off + disallowing reading it through
php://input).
With
There are a lot of values to disable POST completely. That's also why
thinking the option you are proposing while keeping in mind the whole
picture makes sense.
There are different existing modes and one or two new modes (to be
introduced, like disabling POST). Having a clean way to choose which
On Thu, Dec 16, 2010 at 2:16 PM, Pierre Joye pierre@gmail.com wrote:
There are a lot of values to disable POST completely. That's also why
thinking the option you are proposing while keeping in mind the whole
picture makes sense.
There are different existing modes and one or two new
doing something badly designed only because we can do it is a very bad idea.
On Thu, Dec 16, 2010 at 2:51 PM, Ferenc Kovacs i...@tyrael.hu wrote:
http://en.wikipedia.org/wiki/Nirvana_fallacy
If you think that there is a better alternative, please write an RFC and or
a patch, but I don't think
On Thu, Dec 16, 2010 at 3:08 PM, Pierre Joye pierre@gmail.com wrote:
doing something badly designed only because we can do it is a very bad
idea.
you didn't said that this patch is badly designed, you just said, that with
putting some other ideas together we could come up with a more
On 2010-12-16, Pierre Joye pierre@gmail.com wrote:
There are a lot of values to disable POST completely. That's also why
thinking the option you are proposing while keeping in mind the whole
picture makes sense.
There are different existing modes and one or two new modes (to be
On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2010-12-16, Pierre Joye pierre@gmail.com wrote:
There are a lot of values to disable POST completely. That's also why
thinking the option you are proposing while keeping in mind the whole
picture makes
On 2010-12-16, Pierre Joye pierre@gmail.com wrote:
On Thu, Dec 16, 2010 at 3:18 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2010-12-16, Pierre Joye pierre@gmail.com wrote:
The only way I can see such an action being sensible is if it's also
runtime configurable (i.e.,
I think you over react due to our past mistakes. What I'm trying to explain
is exactly what you want. Efficienty without cinfusionsconfusions, ugly
hacks or features duplication.
And that's what I would like to discuss here instead if just doing it, for
the sake of doing it.
On 16 Dec 2010
Hi:
From my point of view the right thing to do with regard to properties is
defined in the test cases below.
The rational behind providing this semantics is based on the fact that PHP
allows to define properties dynamically anyway, so there is no way around
properties.
However, there should
Am 16.12.2010 16:25, schrieb Stefan Marr:
From my point of view the right thing to do with regard to
properties is defined in the test cases below.
+1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
I like it,
additionally if you want to prevent conflicts from the start you can
always go and define prefixed property names like below and use a getter to
access them conveniently.
trait Foo
{
private $Foo_prop;
public function getProp()
{
return $this-Foo_prop;
On Thu, 16 Dec 2010 14:53:08 -, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2010-12-16, Pierre Joye pierre@gmail.com wrote:
I never said it should be a php.ini option, or only a php.ini option.
But having 300 ways to do the same things, or to change options is
bad. You
Hi!
ICU btw has some global stuff too.
I think it's clear that having any global stuff does not necessarily make
the code thread-unsafe.
Oh, this one does. It's not crash-unsafe, just weird-bugs-unsafe.
It's my only guess - this is because a correct sorting of words in some
languages
On 2010-12-16, Stefan Marr p...@stefan-marr.de wrote:
From my point of view the right thing to do with regard to properties
is defined in the test cases below.
The rational behind providing this semantics is based on the fact that
PHP allows to define properties dynamically anyway, so there
On Thu, Dec 16, 2010 at 6:09 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
In short, I don't think the possibility of a future implementation of more
high level mechanisms should preclude the existence of low level ones such
as the proposed and committed enable_post_data_processing, as the
2010/12/16 Stefan Marr p...@stefan-marr.de:
Hi:
From my point of view the right thing to do with regard to properties is
defined in the test cases below.
The rational behind providing this semantics is based on the fact that PHP
allows to define properties dynamically anyway, so there is
Gustavo Lopes wrote:
I know you're responding to Pierre's proposed addition of a way to
disable POST data handling altogether possibly via an ini option, but
since the objection also applies to the ini option I've added to
trunk, I'd like to address it.
Yes, it sucks that the option cannot
Gustavo Lopes wrote:
I've committed to trunk the patch with the name of the ini option changed
from disable_post_data_processing to enable_post_data_reading.
Pierre Joye wrote:
hi,
The more I look at this option the more I think it is confusing. I'm
not sure the gain is worth this
Note that this is already possible by setting post_max_size to 0M. Was
useful prior to the APC upload hooks for writing progress bars.
2010/12/16 Ángel González keis...@gmail.com
Gustavo Lopes wrote:
I've committed to trunk the patch with the name of the ini option changed
from
I am fine with this approach, with 2 caveats:
- If you actually do want to make two traits use the same property, it
looks like the answer here is Either have no property and demand the
existence of an accessor that returns by reference, or you can't write
E_NOTICE-safe code. Is that true?
Hello,
I hereby ask for access to security related bugs with the security flag set.
I was pointed here by Pierre Joye to formally request this.
Thanks in advance.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
31 matches
Mail list logo
