Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
I would guess nobody should be using anything older than BIND 8? So it would make sense to switch to the new symbols and if someone gets compile error, it's just their too old BIND version..? --Jani On Mon, 20 Oct 2003, Marko Karppinen wrote: >On Oct 17, 2003, at 18:57, Christian Stocker wrote: >> I run into the same problem (OS X 10.3). the following patch would fix >> it quick&dirty ;) >> >> shall I commit it? >> or should we even define BIND_8_COMPAT always? > >Well, if nobody is stepping up to do this the "right" way, ie. >switching to the new >result type symbols introduced with BIND 8, you should just commit this >patch. It at least allows people to compile PHP without tricks on the >affected >systems. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Mon, 20 Oct 2003, Jani Taskinen wrote: > > I would guess nobody should be using anything older than BIND 8? > So it would make sense to switch to the new symbols and if someone > gets compile error, it's just their too old BIND version..? Yes, bind 4 doesn't have the "new" ns_t_a things, bind 8 has afaik. Derick -- "Interpreting what the GPL actually means is a job best left to those that read the future by examining animal entrails." - Derick Rethans http://derickrethans.nl/ International PHP Magazine http://php-mag.net/ - -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
A little more investigation revealed that BIND_8_COMPAT is some Apple invention. The official BIND sources have BIND_4_COMPAT, which is the correct one. Try search with Google for BIND_8_COMPAT and then BIND_4_COMPAT for some references. Then go and report bug to Apple folks. :) --Jani On Mon, 20 Oct 2003, Jani Taskinen wrote: > >I would guess nobody should be using anything older than BIND 8? >So it would make sense to switch to the new symbols and if someone >gets compile error, it's just their too old BIND version..? > >--Jani > > >On Mon, 20 Oct 2003, Marko Karppinen wrote: > >>On Oct 17, 2003, at 18:57, Christian Stocker wrote: >>> I run into the same problem (OS X 10.3). the following patch would fix >>> it quick&dirty ;) >>> >>> shall I commit it? >>> or should we even define BIND_8_COMPAT always? >> >>Well, if nobody is stepping up to do this the "right" way, ie. >>switching to the new >>result type symbols introduced with BIND 8, you should just commit this >>patch. It at least allows people to compile PHP without tricks on the >>affected >>systems. >> > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
Why not do some simple #ifdefs like: #ifndef T_A # define T_A ns_t_a #endif This should work always... At 12:06 20.10.2003, Jani Taskinen wrote: A little more investigation revealed that BIND_8_COMPAT is some Apple invention. The official BIND sources have BIND_4_COMPAT, which is the correct one. Try search with Google for BIND_8_COMPAT and then BIND_4_COMPAT for some references. Then go and report bug to Apple folks. :) --Jani On Mon, 20 Oct 2003, Jani Taskinen wrote: > >I would guess nobody should be using anything older than BIND 8? >So it would make sense to switch to the new symbols and if someone >gets compile error, it's just their too old BIND version..? > >--Jani > > >On Mon, 20 Oct 2003, Marko Karppinen wrote: > >>On Oct 17, 2003, at 18:57, Christian Stocker wrote: >>> I run into the same problem (OS X 10.3). the following patch would fix >>> it quick&dirty ;) >>> >>> shall I commit it? >>> or should we even define BIND_8_COMPAT always? >> >>Well, if nobody is stepping up to do this the "right" way, ie. >>switching to the new >>result type symbols introduced with BIND 8, you should just commit this >>patch. It at least allows people to compile PHP without tricks on the >>affected >>systems. >> > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Erlangen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Oct 20, 2003, at 13:06, Jani Taskinen wrote: A little more investigation revealed that BIND_8_COMPAT is some Apple invention. The official BIND sources have BIND_4_COMPAT, which is the correct one. Try search with Google for BIND_8_COMPAT and then BIND_4_COMPAT for some references. I don't think that's true; I think BIND 8 had BIND_4_COMPAT and now BIND 9 changed that to BIND_8_COMPAT (seems like a pretty boneheaded thing to do, but that's what we have...) I guess the biggest difference is that for most BIND 8 installations, BIND_4_COMPAT was on by default, so this problem didn't raise its head. BIND_8_COMPAT isn't set by default on BIND 9, so that's why the PHP compile chokes. Uwe suggested something like #ifndef T_A # define T_A ns_t_a #endif Which might work, although I'd suggest doing it the other way, ie. using the new, non-deprecated names in the actual code. mk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Monday 20 October 2003 13:26, Marko Karppinen wrote: > On Oct 20, 2003, at 13:06, Jani Taskinen wrote: > > A little more investigation revealed that BIND_8_COMPAT is some > > Apple invention. The official BIND sources have BIND_4_COMPAT, > > which is the correct one. Try search with Google for BIND_8_COMPAT > > and then BIND_4_COMPAT for some references. > > I don't think that's true; I think BIND 8 had BIND_4_COMPAT > and now BIND 9 changed that to BIND_8_COMPAT (seems like > a pretty boneheaded thing to do, but that's what we have...) Not really. Jani is right. The whole compatibility layer is already in the official Bind9 sources and enabled by default: /* * $Id: nameser.h,v 1.2.2.3 2002/07/14 04:26:55 marka Exp $ */ #ifndef _ARPA_NAMESER_H_ #define _ARPA_NAMESER_H_ #define BIND_4_COMPAT #ifdef BIND_4_COMPAT #include #endif Apple devs have re-invented the wheel and made it square. Question is - what else is triggered with BIND_8_COMPAT in the apple source tree, cause there must be some alternate reason to do this, other than "There never was a bind4 on apple, so let's rename it". -- Melvyn -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
Because it's done by the nameser_compat.h which is included by default by nameser.h. (this applies to official BIND sources) --Jani On Mon, 20 Oct 2003, Uwe Schindler wrote: >Why not do some simple #ifdefs like: >#ifndef T_A ># define T_A ns_t_a >#endif > >This should work always... > >At 12:06 20.10.2003, Jani Taskinen wrote: > >> A little more investigation revealed that BIND_8_COMPAT is some >> Apple invention. The official BIND sources have BIND_4_COMPAT, >> which is the correct one. Try search with Google for BIND_8_COMPAT >> and then BIND_4_COMPAT for some references. >> >> Then go and report bug to Apple folks. :) >> >> --Jani >> >> >>On Mon, 20 Oct 2003, Jani Taskinen wrote: >> >> > >> >I would guess nobody should be using anything older than BIND 8? >> >So it would make sense to switch to the new symbols and if someone >> >gets compile error, it's just their too old BIND version..? >> > >> >--Jani >> > >> > >> >On Mon, 20 Oct 2003, Marko Karppinen wrote: >> > >> >>On Oct 17, 2003, at 18:57, Christian Stocker wrote: >> >>> I run into the same problem (OS X 10.3). the following patch would fix >> >>> it quick&dirty ;) >> >>> >> >>> shall I commit it? >> >>> or should we even define BIND_8_COMPAT always? >> >> >> >>Well, if nobody is stepping up to do this the "right" way, ie. >> >>switching to the new >> >>result type symbols introduced with BIND 8, you should just commit this >> >>patch. It at least allows people to compile PHP without tricks on the >> >>affected >> >>systems. >> >> >> > >> > >> >>-- >>PHP Internals - PHP Runtime Development Mailing List >>To unsubscribe, visit: http://www.php.net/unsub.php > >- >Uwe Schindler >[EMAIL PROTECTED] - http://www.php.net >NSAPI SAPI developer >Erlangen, Germany > -- https://www.paypal.com/xclick/[EMAIL PROTECTED]&no_note=1&tax=0¤cy_code=EUR -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Mon, 20 Oct 2003, Marko Karppinen wrote: >On Oct 20, 2003, at 13:06, Jani Taskinen wrote: >> A little more investigation revealed that BIND_8_COMPAT is some >> Apple invention. The official BIND sources have BIND_4_COMPAT, >> which is the correct one. Try search with Google for BIND_8_COMPAT >> and then BIND_4_COMPAT for some references. > >I don't think that's true; I think BIND 8 had BIND_4_COMPAT >and now BIND 9 changed that to BIND_8_COMPAT (seems like >a pretty boneheaded thing to do, but that's what we have...) I suggest you get your facts straight before basically calling me a liar. I checked the latest released version of BIND (9.2.2P3) and it has NO such thing as 'BIND_8_COMPAT' anywhere in it. >I guess the biggest difference is that for most BIND 8 installations, >BIND_4_COMPAT was on by default, so this problem didn't >raise its head. BIND_8_COMPAT isn't set by default on BIND 9, >so that's why the PHP compile chokes. Read what I said, once more. We can't start adding some Apple specific shit for stuff that HAS to be standard.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Oct 20, 2003, at 14:44, Jani Taskinen wrote: I suggest you get your facts straight before basically calling me a liar. I checked the latest released version of BIND (9.2.2P3) and it has NO such thing as 'BIND_8_COMPAT' anywhere in it. You are right, I was wrong. Sorry. There's quite a difference, however, between being misinformed and hence not agreeing with you and calling you a liar... Also, I'd like to mention that this isn't really about Apple and their stupid header mangling, it's about the gazillion users of their platform. Anyway, knowing what your view is on hacks for "Apple specific shit" I'll just give up trying to get a change into the tree. When Mac OS X 10.3 comes out this week -- with this problem -- someone will probably just make a third-party binary or a funky patch kit. I don't care. People trying to respond to bugs.php.net reports might care, though, so you should probably just send Mac-specific reports into /dev/null in anticipation of that flood. mk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
Marko, the world does not revolve around Apple, as much as you would like it to. :) And I will bogus each and every bug report about this and tell them to report this bug in MacOSX where it belongs: Apple. About "people trying to respond to bugs.php.net reports".. That's basically me, so you don't need to worry about it. --Jani On Mon, 20 Oct 2003, Marko Karppinen wrote: >Also, I'd like to mention that this isn't really about Apple and their >stupid header mangling, it's about the gazillion users of their >platform. > >Anyway, knowing what your view is on hacks for "Apple specific >shit" I'll just give up trying to get a change into the tree. When >Mac OS X 10.3 comes out this week -- with this problem -- someone >will probably just make a third-party binary or a funky patch kit. >I don't care. > >People trying to respond to bugs.php.net reports might care, >though, so you should probably just send Mac-specific >reports into /dev/null in anticipation of that flood. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Oct 20, 2003, at 15:47, Jani Taskinen wrote: Marko, the world does not revolve around Apple, as much as you would like it to. :) Of course it doesn't. But you should consider Apple to be a big, fat, slow-moving commercial platform vendor, which it is. If I had a one-line patch that would solve compile bustage on Windows, for example, I would be more inclined to apply it than to wait for Microsoft to fix their operating system. In that case, I'd consider the Windows-based users more important than bashing Windows -- even though I, as you know, also enjoy Windows-bashing very much. So, here's my suggestion: 1. I'll add BIND_8_COMPAT to the darwin-specific part of configure.in, so its nature as a darwin hack is clear to everyone. 2. In exchange for introducing this APPLE-SPECIFIC SHIT, I'll remove some non-needed Darwin crud from ext/standard/dns.c. Measured in lines of code, the amount of Apple-specific shit will actually decrease in the codebase. And you'd have to be happy about that :) mk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Mon, 20 Oct 2003, Marko Karppinen wrote: >1. I'll add BIND_8_COMPAT to the darwin-specific part of >configure.in, so its nature as a darwin hack is clear to everyone. Very good idea. >2. In exchange for introducing this APPLE-SPECIFIC SHIT, >I'll remove some non-needed Darwin crud from ext/standard/dns.c. > >Measured in lines of code, the amount of Apple-specific shit >will actually decrease in the codebase. And you'd have to >be happy about that :) Anyway, don't forget there are also other projects than PHP that rely on these header files, so wouldn't it make sense to let Apple know BEFORE they release the new MacOSX version? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
On Oct 20, 2003, at 16:09, Jani Taskinen wrote: Anyway, don't forget there are also other projects than PHP that rely on these header files, so wouldn't it make sense to let Apple know BEFORE they release the new MacOSX version? Sure. I've known about this since June, but unfortunately didn't investigate it enough to realize that it is an Apple problem. And now the new version is already in duplication and will be available, shrink-wrapped, in stores this Friday. Which is why the "complain to Apple" approach doesn't help with the 10.3 release. But I'll report it nonetheless. mk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
At 04:18 PM 10/20/2003 +0300, Marko Karppinen wrote: On Oct 20, 2003, at 16:09, Jani Taskinen wrote: Anyway, don't forget there are also other projects than PHP that rely on these header files, so wouldn't it make sense to let Apple know BEFORE they release the new MacOSX version? Sure. I've known about this since June, but unfortunately didn't investigate it enough to realize that it is an Apple problem. And now the new version is already in duplication and will be available, shrink-wrapped, in stores this Friday. Which is why the "complain to Apple" approach doesn't help with the 10.3 release. But I'll report it nonetheless. It should be reported but I agree with Marko that PHP should support some work around in the meanwhile. It always takes vendors some time to fix their stuff and we should do what's best for our user base which is create a working version of PHP ASAP. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alternative for foreach ()
At 2003-10-19 13:38 +0100, Wez Furlong wrote: >> It wouldn't surprise me when the foreach syntax would be >> deprecated soon... > >If you're trying to humourous, I suggest that you first earn >some karma by contributing some real code to the PHP project. > >Your suggestion will not be implemented because it is >redundant and confusing to have yet another way to iterate >an array, especially a syntax that doesn't fit with the PHP >spirit. Why doesn't it fit the 'PHP spirit'? I think the 'foreach (as)' construct is very foreign to PHP or any C-like language. Algol on which C is based, already allowed the assignment of elements from a set (in the form of a list of expressions) in a for-loop something like this: for x=1,2,5..8 All C-like and indeed almost all higher languages have always had their assignments flowing to the left in an expression. I think it's a mistake to reverse this suddenly for a new construct in PHP, but perhaps you can explain the logic of it to me. Until you do I can't help but seeing it as a 'perl-ification' of PHP. And why be so hostile? I used to write my own compilers, assemblers and linkers and lately I contributed this Amazon webservices script to the world: http://www.chipdir.nl/amazon/ (No it's not big science, but it saves people who are interested in this subject having to plough through miles of Amazon's vague documentation and non-working as-is scripts. And whenever someone criticizes whatever I made I take it very seriously based on what they say and not on their status of cooperator or whatever. Since 1995 I provide a free WWW information site about chips to the world: http://www.chipdir.org/ and from the logs I have seen that (even) employees from all major corporations have been consulting it, so probably at least one piece of hardware you're using (directly or indirectly) has been designed with the use of my site. Perhaps it's next time when you fly a plane... Greetings, Jaap PS. Is there a separate mailing list for discussing design issues of PHP as opposed to implementation issues? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_4_3) / configure.in /main php_version.h
How about we automatically concat EXTRA_VERSION with the PHP_VERSION in php_version.h? Does anyone see a problem with that? Andi On Mon, 20 Oct 2003, Ilia Alshanetsky wrote: > iliaa Mon Oct 20 12:08:22 2003 EDT > > Modified files: (Branch: PHP_4_3) > /php-src configure.in > /php-src/main php_version.h > Log: > RC2 is a go. > > > Index: php-src/configure.in > diff -u php-src/configure.in:1.396.2.80 php-src/configure.in:1.396.2.81 > --- php-src/configure.in:1.396.2.80 Tue Oct 7 06:04:51 2003 > +++ php-src/configure.in Mon Oct 20 12:08:16 2003 > @@ -1,4 +1,4 @@ > -dnl ## $Id: configure.in,v 1.396.2.80 2003/10/07 10:04:51 helly Exp $ -*- sh -*- > +dnl ## $Id: configure.in,v 1.396.2.81 2003/10/20 16:08:16 iliaa Exp $ -*- sh -*- > dnl ## Process this file with autoconf to produce a configure script. > > divert(1) > @@ -41,7 +41,7 @@ > MAJOR_VERSION=4 > MINOR_VERSION=3 > RELEASE_VERSION=4 > -EXTRA_VERSION="RC2-dev" > +EXTRA_VERSION="RC2" > VERSION="$MAJOR_VERSION.$MINOR_VERSION.$RELEASE_VERSION$EXTRA_VERSION" > > dnl Define where extension directories are located in the configure context > Index: php-src/main/php_version.h > diff -u php-src/main/php_version.h:1.66.2.32 php-src/main/php_version.h:1.66.2.33 > --- php-src/main/php_version.h:1.66.2.32 Mon Sep 29 20:35:52 2003 > +++ php-src/main/php_version.hMon Oct 20 12:08:17 2003 > @@ -3,5 +3,5 @@ > #define PHP_MAJOR_VERSION 4 > #define PHP_MINOR_VERSION 3 > #define PHP_RELEASE_VERSION 4 > -#define PHP_EXTRA_VERSION "RC2-dev" > -#define PHP_VERSION "4.3.4RC2-dev" > +#define PHP_EXTRA_VERSION "RC2" > +#define PHP_VERSION "4.3.4RC2" > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_4_3) / configure.in /main php_version.h
On October 20, 2003 12:27 pm, Andi Gutmans wrote: > How about we automatically concat EXTRA_VERSION with the PHP_VERSION in > php_version.h? Does anyone see a problem with that? Sounds like a good idea to me :) Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.3.4RC2 Released
FYI PHP 4.3.4RC2 was just released, please test it as much as possible to uncover any bugs that remain. Unless any major issues are discovered 4.3.4 will be released in one week's time. I would like to ask developers to refrain from making commits to the 4.3.X tree unless the patch solves a BC or security issue until 4.3.4 is released. Thanks, Ilia P.S. Please test it :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] request for thread safety advice
Hi, internals. Please send me (post here i mean) a few links about 1. thread safety in general 2. thread saftey in php 3. I'm doing wrapper for librep wich is not thread safe (so mailing archives say). Do I need to know something special ? After doing some googling i found thise for #1 http://www.unix.org/version2/whatsnew/threads.html http://www.unix.org/version2/whatsnew/threadsref.html is that a good reading ? any better suggestions for google requests than thise : c thread safety -mail -archive -lists c thread safety tutor ? I couldn't find anything for #2 but it's not less important than #1 :) -- NetCat -- SPAM-Free 10mb Free email + Antivirus + POP3 + more... Get it at http://www.doal.co.il:81/free/?c=all-spam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request for thread safety advice
If the library you are wrapping is not threadsafe, one approach is to simply not worry about it and just mark your extension as not being safe to use in a threaded environment. The majority of people use PHP in a non-threaded environment anyway. If you want to be nice to the folks who do use PHP in a threaded environment, you can look into adding a semaphore lock around the calls into the code that is not threadsafe. Such a semaphore lock makes sure that only 1 thread at a time can enter the code. Other threads sit around and wait until it is their turn. -Rasmus On Mon, 20 Oct 2003, netcat wrote: > Hi, internals. > > Please send me (post here i mean) a few links about > 1. thread safety in general > 2. thread saftey in php > 3. I'm doing wrapper for librep wich is not thread > safe (so mailing archives say). Do I need to know > something special ? > > > After doing some googling i found thise for #1 > http://www.unix.org/version2/whatsnew/threads.html > http://www.unix.org/version2/whatsnew/threadsref.html > is that a good reading ? > > any better suggestions for google requests than thise : > c thread safety -mail -archive -lists > c thread safety tutor > ? > > I couldn't find anything for #2 but it's not less > important than #1 :) > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request for thread safety advice
nice for that would be some macros (somewhere in zend) which help in
the following way (the ext_skel should generate the code, too):
a) define a global library identifier (for all blocks that should not run
at the same time)
zend_create_mutex(identifier)
b) use some code like:
zend_start_synchronized(identifier) {
...
...
} zend_end_synchronized(identifier);
(Same construct like zend_try). Without ZTS this macros should be empty...
As I am the developer of the NSAPI SAPI (which runs only with ZTS) I would
like to have a GD extension where alle PHP_FUNCTIONs exported from there
should have such Java-like "synchronized" blocks.
Uwe
At 00:10 21.10.2003, you wrote:
If the library you are wrapping is not threadsafe, one approach is to
simply not worry about it and just mark your extension as not being safe
to use in a threaded environment. The majority of people use PHP in a
non-threaded environment anyway.
If you want to be nice to the folks who do use PHP in a threaded
environment, you can look into adding a semaphore lock around the calls
into the code that is not threadsafe. Such a semaphore lock makes sure
that only 1 thread at a time can enter the code. Other threads sit around
and wait until it is their turn.
-Rasmus
On Mon, 20 Oct 2003, netcat wrote:
> Hi, internals.
>
> Please send me (post here i mean) a few links about
> 1. thread safety in general
> 2. thread saftey in php
> 3. I'm doing wrapper for librep wich is not thread
> safe (so mailing archives say). Do I need to know
> something special ?
>
>
> After doing some googling i found thise for #1
> http://www.unix.org/version2/whatsnew/threads.html
> http://www.unix.org/version2/whatsnew/threadsref.html
> is that a good reading ?
>
> any better suggestions for google requests than thise :
> c thread safety -mail -archive -lists
> c thread safety tutor
> ?
>
> I couldn't find anything for #2 but it's not less
> important than #1 :)
>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request for thread safety advice
The question is if this is always enough. Say for example hypothetically
that the GD library saves the state of the currently being manipulated
graphic, it won't be enough to mutex its calls because there's some saved
state in between the calls.
I'm not sure there's a general way to deal with it. Sure you could have
some general code for a mutex but I don't think that'll solve all of the
problems.
Andi
At 02:06 AM 10/21/2003 +0200, Uwe Schindler wrote:
nice for that would be some macros (somewhere in zend) which help in
the following way (the ext_skel should generate the code, too):
a) define a global library identifier (for all blocks that should not run
at the same time)
zend_create_mutex(identifier)
b) use some code like:
zend_start_synchronized(identifier) {
...
...
} zend_end_synchronized(identifier);
(Same construct like zend_try). Without ZTS this macros should be empty...
As I am the developer of the NSAPI SAPI (which runs only with ZTS) I would
like to have a GD extension where alle PHP_FUNCTIONs exported from there
should have such Java-like "synchronized" blocks.
Uwe
At 00:10 21.10.2003, you wrote:
If the library you are wrapping is not threadsafe, one approach is to
simply not worry about it and just mark your extension as not being safe
to use in a threaded environment. The majority of people use PHP in a
non-threaded environment anyway.
If you want to be nice to the folks who do use PHP in a threaded
environment, you can look into adding a semaphore lock around the calls
into the code that is not threadsafe. Such a semaphore lock makes sure
that only 1 thread at a time can enter the code. Other threads sit around
and wait until it is their turn.
-Rasmus
On Mon, 20 Oct 2003, netcat wrote:
> Hi, internals.
>
> Please send me (post here i mean) a few links about
> 1. thread safety in general
> 2. thread saftey in php
> 3. I'm doing wrapper for librep wich is not thread
> safe (so mailing archives say). Do I need to know
> something special ?
>
>
> After doing some googling i found thise for #1
> http://www.unix.org/version2/whatsnew/threads.html
> http://www.unix.org/version2/whatsnew/threadsref.html
> is that a good reading ?
>
> any better suggestions for google requests than thise :
> c thread safety -mail -archive -lists
> c thread safety tutor
> ?
>
> I couldn't find anything for #2 but it's not less
> important than #1 :)
>
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] request for thread safety advice
True, I should have mentioned that the mutex might have to span an entire
sequence of calls from open to close or something to that effect.
In the specific case of GD, it wouldn't actually be hard to make it
threadsafe. Shane did it before to GD1 and it should probably be done
again for our bundled version of GD2.
-Rasmus
On Tue, 21 Oct 2003, Andi Gutmans wrote:
> The question is if this is always enough. Say for example hypothetically
> that the GD library saves the state of the currently being manipulated
> graphic, it won't be enough to mutex its calls because there's some saved
> state in between the calls.
> I'm not sure there's a general way to deal with it. Sure you could have
> some general code for a mutex but I don't think that'll solve all of the
> problems.
>
> Andi
>
> At 02:06 AM 10/21/2003 +0200, Uwe Schindler wrote:
> >nice for that would be some macros (somewhere in zend) which help in
> >the following way (the ext_skel should generate the code, too):
> >
> >a) define a global library identifier (for all blocks that should not run
> >at the same time)
> > zend_create_mutex(identifier)
> >
> >b) use some code like:
> > zend_start_synchronized(identifier) {
> > ...
> > ...
> > } zend_end_synchronized(identifier);
> >
> >(Same construct like zend_try). Without ZTS this macros should be empty...
> >
> >As I am the developer of the NSAPI SAPI (which runs only with ZTS) I would
> >like to have a GD extension where alle PHP_FUNCTIONs exported from there
> >should have such Java-like "synchronized" blocks.
> >
> >Uwe
> >
> >At 00:10 21.10.2003, you wrote:
> >>If the library you are wrapping is not threadsafe, one approach is to
> >>simply not worry about it and just mark your extension as not being safe
> >>to use in a threaded environment. The majority of people use PHP in a
> >>non-threaded environment anyway.
> >>
> >>If you want to be nice to the folks who do use PHP in a threaded
> >>environment, you can look into adding a semaphore lock around the calls
> >>into the code that is not threadsafe. Such a semaphore lock makes sure
> >>that only 1 thread at a time can enter the code. Other threads sit around
> >>and wait until it is their turn.
> >>
> >>-Rasmus
> >>
> >>On Mon, 20 Oct 2003, netcat wrote:
> >>
> >> > Hi, internals.
> >> >
> >> > Please send me (post here i mean) a few links about
> >> > 1. thread safety in general
> >> > 2. thread saftey in php
> >> > 3. I'm doing wrapper for librep wich is not thread
> >> > safe (so mailing archives say). Do I need to know
> >> > something special ?
> >> >
> >> >
> >> > After doing some googling i found thise for #1
> >> > http://www.unix.org/version2/whatsnew/threads.html
> >> > http://www.unix.org/version2/whatsnew/threadsref.html
> >> > is that a good reading ?
> >> >
> >> > any better suggestions for google requests than thise :
> >> > c thread safety -mail -archive -lists
> >> > c thread safety tutor
> >> > ?
> >> >
> >> > I couldn't find anything for #2 but it's not less
> >> > important than #1 :)
> >> >
> >> >
> >> >
> >>
> >>--
> >>PHP Internals - PHP Runtime Development Mailing List
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >-
> >Uwe Schindler
> >[EMAIL PROTECTED] - http://www.php.net
> >NSAPI SAPI developer
> >Erlangen, Germany
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 5 Beta 2
Andi, is/was someone planning on looking into the problem of class constants for internal classes? i'll include a comment (from Moriyoshi) in our project as a reference /* * XXX: zend_initialize_class_data() is totally mess! because it * virtually doesn't take it into account that the constants of * internal classes are persistently allocated while they will actually * be destroyed by the normal ZVAL_PTR_DTOR() which accepts zvals * allocated by emalloc(). * That's why I prepared my own zval destructors. But this workaround is * not safe yet because all the symbols bound dynamically by the Zend engine * are supposed to be released before the destruction of class entries * registered by extensions at the engine shutdown. * So this extension has to be linked statically to the PHP runtime for now. * .. :( */ that's the only outstanding issue i have personally with the beta. otherwise the current CVS works well. ive tested the new read/write dimension hooks, object level iterators, as well as casting, and they work as expected. l0t3k "Andi Gutmans" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hey, > > I'd like to release Beta 2 at the end of the week after next (30th of > October). Please make sure your code is ready by then. If there's anything > critical that can't be ready on time please let me know (although I doubt > there is such a thing). > Beta 2 will be a big step forward from beta 1 and I think once it's out > it'll allow us to build the necessary momentum for releasing beta's of PHP > 5 more often. > > Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 4.3.4 compile on BIND9 systems
In message <[EMAIL PROTECTED]> on Mon, Oct 20, 2003 at 02:44:48PM +0300, Jani Taskinen wrote: > We can't start adding some Apple specific shit for PHP already contains OS-specific excrement (including lines that are Linux-specific, Jani, whether it's acknowledged or not). Different systems differ. Is this not one reason why autoconf/automake/libtool exist? If there is some concern that defining BIND_8_COMPAT may conflict with future definitions of that symbol, perhaps you could #if HAVE_ARPA_NAMESER_COMPAT_H #include #endif Although it seems unbelievable that BIND_4_COMPAT would been removed from Darwin (must have happened this year?), it sounds like a naming issue only (with no semantics being affected). In message <[EMAIL PROTECTED]> on Mon, Oct 20, 2003 at 03:25:12PM +0200, Andi Gutmans wrote: > It should be reported but I agree with Marko that PHP should support some > work around in the meanwhile. It always takes vendors some time to fix > their stuff and we should do what's best for our user base which is create > a working version of PHP ASAP. ^^^ I genuinely appreciate that sentiment. It is promising to hear a voice of reason. In message <[EMAIL PROTECTED]> on Mon, Oct 20, 2003 at 02:44:48PM +0300, Jani Taskinen wrote: > stuff that HAS to be standard.. Regardless of BIND9/Darwin issues, PHP 4.3.4RC2 (as is typical of 4.3 versions) fails to compile with a number of "standard", open-source libraries that other software has no problem with. In some (rare?) cases, PHP might not be at fault from a developer's perspective (and it appears BIND9 is one such situation!), yet PHP may very well behave as though it's at fault (from a package maintainer or end-user's point of view). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
