headers
Lucas Nealan | 1 Aug 2008 05:01

Re: [PHP-DEV] [RFC] Zend Signal Handling

> On 7/30/08 6:11 AM, "Lukas Kahwe Smith" <mls <at> pooteeweet.org> wrote:
> Not so happy that it was not possible to get this committed over the
> weekend. Johannes did a quick review and it seems like it has enough
> support from people and is low risk enough to get committed now. Lets
> hope no extension stumbled over this one ..
>  <at> Dmitry: Can you get this applied today?
>> On 7/30/08 9:37 AM, "Dmitry Stogov" <dmitry <at> zend.com> wrote:
>> I think it's not a good idea to commit it in this state.
>> Correct me, if I'm wrong. I've done just a very quick review.
>> Thanks. Dmitry.

Sorry about the delay getting some of these things worked on over the
weekend. I had to recover from OSCON and didn't get a chance to look at
things until back in the office. Seems as though I've been given a stay and
can land in Alpha 2 once some more work is done. Thanks for this.

In response to Dmitry's feedback and some others:

> On 7/30/08 9:37 AM, "Dmitry Stogov" <dmitry <at> zend.com> wrote:
> I see several issues with the patch
> 1) It assumes that web server (and webserver extensions) won't setup any
> signal handlers after PHP startup. This assumption may be wrong.
>> On 7/30/08 9:50 AM, "Rasmus Lerdorf" <rasmus <at> lerdorf.com> wrote:
>> It may be.  But there is really no way around that.  That's why we
>> talked about having an optional request shutdown check that would tell
>> you if something hi-jacked one of the signals so at least you know that
>> this is happening.

I have to go with what Rasmus said here, theres not much we can do. It seems
pretty unlikely since the new signal handler would have to be installed via
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lucas Nealan | 1 Aug 2008 05:39

Re: [PHP-DEV] [RFC] Zend Signal Handling

On 7/30/08 11:54 AM, "Stanisla Malyshev" <stas <at> zend.com> wrote:
> I have a couple of questions about the patch:
> 1. Why allocate fixed-size buffer via individual malloc's on each
> activate and free it on each deactivate? Won't it be better to just
> allocate it once and use it?

I'll take a look at this. I can't think of a reason not to avoid the alloc's
per request.    

> 2. Why define own SIG_UNEXPECTED - we already have UNEXPECTED macro in
> the engine?

Good question. Trying to remember.... Ok yeah, it's not coming to me. Unless
it comes randomly into my head I'll switch this over.

> 3. I understand that ZEND_SIGNALS is disabled whenever ZTS is on.
> However, in the code I see parts where under ifdef ZEND_SIGNALS there's
> still checks for ifdef ZTS. Why is that? Is it planned to be implemented
> on some stage?

I was initially planning to implement ZTS, however the more I learned the
harder it became. The first issue being that not every scope implementing
the blocking macros has implemented or fetched TSRMLS data. Many places in
zend_alloc.c for example fail with the new macro's because of the missing
rsrc_id. Also, while this will eventually add some safer ZTS blocking
protection it will definitely come at a performance cost instead of the gain
we might see in non-zts mode. I wasn't ready to jump in a start changing too
much of zend for this to be possible. Most of these are in zend_alloc.c and
zend_hash.c.
(Continue reading)

Permalink | Reply | 37 comments |
headers
Arnaud Le Blanc | 1 Aug 2008 08:07
Picon

Re: [PHP-DEV] [RFC] Zend Signal Handling

Hi,

On Friday 01 August 2008 05:39:27 Lucas Nealan wrote:
> I was initially planning to implement ZTS, however the more I learned the
> harder it became. The first issue being that not every scope implementing
> the blocking macros has implemented or fetched TSRMLS data. Many places in
> zend_alloc.c for example fail with the new macro's because of the missing
> rsrc_id. Also, while this will eventually add some safer ZTS blocking
> protection it will definitely come at a performance cost instead of the gain
> we might see in non-zts mode.
> I wasn't ready to jump in a start changing too 
> much of zend for this to be possible. Most of these are in zend_alloc.c and
> zend_hash.c.
> 
> In addition we'd need also need to figure out how manage signal delivery to
> the right thread. 

I worked a bit on the ZTS version, this actually fixes many problems with ZTS 
on non-windows plateforms :) 

For the delivery to the right thread, there will be no problem as long as the 
signal is sent to a specific thred (and not to the whole process).

setitimer() for example will send the SIGALRM/SIGPROF signal to the calling 
thread, so the signal will be delivered to the thread which exceeded 
max_execution_time.

For the ts resources however this effectively needs some TSRMLS_FETCH(). As 
_emalloc() and some others already use TSRMLS_FETCH() I guess it may be 
possible to just pass the TSRM arguments to those functions.
(Continue reading)

Permalink | Reply | 36 comments |
headers
Marcus Boerger | 1 Aug 2008 08:24
Picon

Re: [PHP-DEV] PEAR Build fix

Hello Rasmus,

Wednesday, July 30, 2008, 4:12:35 PM, you wrote:

> Could someone please fix this:

> Generating phar.php
> Generating phar.phar
> Pear package PHP_Archive found: API Version: 1.0.0 (stable).
> Pear package PHP_Archive or Archive.php class file not found.
> clicommand.inc
> directorygraphiterator.inc
> directorytreeiterator.inc
> invertedregexiterator.inc
> pharcommand.inc
> phar.inc

> Build complete.
> Don't forget to run 'make test'.

> The problem is that in phar.php it does a

>    pear list-files PHP_Archive

> This outputs a bunch of filenames ending with:

> test /usr/local/lib/php/test/PHP_Archive/tests/test_require.php
> test /usr/local/lib/php/test/PHP_Archive/tests/test_tar.tar
> test /usr/local/lib/php/test/PHP_Archive/tests/twophars.phpt
> php  /usr/local/lib/php/PHP/Archive.php
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lukas Kahwe Smith | 1 Aug 2008 09:31
Picon

PHP 5.3.0alpha1

Hello!

Johannes has packed PHP 5.3.0alpha1 yesterday evening, which you can  
find here:
http://downloads.php.net/johannes/

Please test it carefully, and report any bugs in the bug system, but  
only if you have a short reproducable test case. The final release is  
expected sometime between mid September and mid October. You can read  
more information about this release here:
http://www.php.net/archive/2008.php#id2008-08-01-1

regards,
Johannes and Lukas

--

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 4 comments |
headers
Antony Dovgal | 1 Aug 2008 12:11
Favicon
Gravatar

[PHP-DEV] enabling everything by default

Hello all.

I'd like to express my feelings on the "let's-enable-it-by-default" mood that has emerged lately.

Extensions enabled by default in 5.2:
ctype
date
dom
filter
hash
iconv
json
libxml
pcre
PDO
pdo_sqlite
posix
Reflection
session
SimpleXML
SPL
SQLite
standard
tokenizer
xml
xmlreader
xmlwriter
-----
Total: 22 extensions
(Continue reading)

Permalink | Reply | 40 comments |
headers
Scott MacVicar | 1 Aug 2008 12:20
Gravatar

Re: [PHP-DEV] enabling everything by default


Antony Dovgal wrote:
> Hello all.
> 
> I'd like to express my feelings on the "let's-enable-it-by-default" mood 
> that has emerged lately.
> 
> Extensions enabled by default in 5.2:
> ctype
> date
> dom
> filter
> hash
> iconv
> json
> libxml
> pcre
> PDO
> pdo_sqlite
> posix
> Reflection
> session
> SimpleXML
> SPL
> SQLite
> standard
> tokenizer
> xml
> xmlreader
> xmlwriter
(Continue reading)

Permalink | Reply | 10 comments |
headers
Antony Dovgal | 1 Aug 2008 12:30
Favicon
Gravatar

Re: [PHP-DEV] enabling everything by default

On 01.08.2008 14:20, Scott MacVicar wrote:
> ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its just 
> another wrapper but without the PDO crap on top.

I know, I know.
But why enable it by default (as well as PDO_SQLITE)? 
What's so extremely useful in this extension that every user needs it?

> If you have ideas on testing without enabling them or bundling in the 
> build please do share. It's a chicken and egg situtation imho.

Testing doesn't require enabling it by default.
In fact, it doesn't even require putting the extension in the core, 
though this surely increases the the amount of feedback.
Developers should test their extensions, not users.

-- 
Wbr, 
Antony Dovgal

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 9 comments |
headers
Scott MacVicar | 1 Aug 2008 12:41
Gravatar

Re: [PHP-DEV] enabling everything by default

Antony Dovgal wrote:
> On 01.08.2008 14:20, Scott MacVicar wrote:
>> ext/pdo_sqlite and ext/sqlite3 use the same underlying lib so its just 
>> another wrapper but without the PDO crap on top.
> 
> I know, I know.
> But why enable it by default (as well as PDO_SQLITE)? What's so 
> extremely useful in this extension that every user needs it?

The zero configuration aspect, the ability to just throw up a database 
in place of your own over complicated storage format. Sure all hosts 
have MySQL but if you're shipping a product then sometimes its simpler 
to just bundle a SQLite DB.

Clientside apps are also moving forward with SQLite, Firefox 3.0, Google 
Gears, Adobe AIR and just about every Apple product. I've been writing 
PHP scripts to start using the data.

I'm happy to disable PDO by default and have you force it on like mysql 
or any of the others.

> 
>> If you have ideas on testing without enabling them or bundling in the 
>> build please do share. It's a chicken and egg situtation imho.
> 
> Testing doesn't require enabling it by default.
> In fact, it doesn't even require putting the extension in the core, 
> though this surely increases the the amount of feedback.
> Developers should test their extensions, not users.
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Antony Dovgal | 1 Aug 2008 12:43
Favicon
Gravatar

Re: [PHP-DEV] enabling everything by default

On 01.08.2008 14:41, Scott MacVicar wrote:
>> I know, I know.
>> But why enable it by default (as well as PDO_SQLITE)? What's so 
>> extremely useful in this extension that every user needs it?
> 
> The zero configuration aspect, the ability to just throw up a database 
> in place of your own over complicated storage format. Sure all hosts 
> have MySQL but if you're shipping a product then sometimes its simpler 
> to just bundle a SQLite DB.

None of this requires enabling it by default.

-- 
Wbr, 
Antony Dovgal

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 3 comments |

Gmane