Re: [PHP-DEV] php 4.3.0 ext/oci8 -- OCI_SHARED patch

[Thies C. Arntzen]

On Tue, Jan 07, 2003 at 11:46:16AM -0500, Levi Dixon wrote:
> 
> I have tested it and it works for me.  As far as thread safety, all of OCI
> could suffer from thread safety problems, not just this feature.  If we want
> ext/oci8 to be thread safe, we should really pass the OCI_THREADED flag into
> OCIInitialize().  At first glance it seems that thread safety should be
> accounted for #ifdef ZTS.  Is this correct?  I can add it if required.

yes - but you only need to use OCI_THREADED if you want oci
to mutex around the use of statements and connections. as we
don't share statements or connections between threads (yet)
we don't need to do that (yet). plus i think it will be
slightly slower. (as you know threads are always slow;-)

    re,
tc

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] zend_timeout and the SIGPROF signal

[Thies C. Arntzen]

On Thu, Feb 20, 2003 at 05:11:55PM +0100, Wojtek Meler wrote:
> On Thu, Feb 20, 2003 at 05:48:29PM +0200, Zeev Suraski wrote:
> > At 17:38 20/02/2003, [EMAIL PROTECTED] wrote:
> > >- Original Message -
> > > > I looked into the bug report, and it is true that
> > > > BLOCK_INTERRUPTIONS
> > > > should indeed block SIGPROF.  I'll fix this in the weekend.
> > >
> > >I'm not sure if after unblocking interruptions PHP will get SIGPROF ...
> > >it could cause long scripts. I'd rather use EG(timeout). I'm using
> > >it now and it's working.
> > 
> > EG(timeout) is a horrible option (I wrote both, SIGPROF is by far 
> > superior).  I'll try to implement a solution that won't lose the SIGPROF.
> 
> It's possible to call zend_bailout if EG(timeout) is set in
> UNBLOCK_INTERRUPTIONS macro. But it doesn't solve main problem - it is
> not safe to just skip the stack - even PHP use locks (TSRM) and its
> memory allocator also use malloc/realloc/free which use locks, so it isn't safe. 
> 
> External libraries uses memory structures which can't be freed if
> paritialy modified (because SIGPROF stops modification in the middle). 
> Trying to free them by PHP resource mechanism can cause SIGSEGV, busy loops etc. 
> Not freeing them we loose memory ...
> 
> I strongly recommend to stop using zend_bailout on timeouts (it's better
> to exit - it will not hang ;)

zeev, remember we discussed the very same thing last year (or
the one before) at linuxtag in frankfurt?

i also think that exit() would be the "clearest" thing. but
it won't help in any threaded environment - so it's not an
option.

thing is - no matter how "clever" it is implemented - calling
longjump from a signal handler is calling for trouble unless
everybody involved beeing very careful about their "critical regions".
especiqal non-threadsafe libs are very likely to not even
have a concept what a critical section is...

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] OCI8 link failure (Tru64/AIX) (#22324)

[Thies C. Arntzen]

> I still think that the best solution would be to check if linking with
> -lcntsh alone is enough to get OCILobIsTemporary, and if not, check if
> it works with -locijdbc8.

i think that makes sense.

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

hi,

this patch adds the extremely useful debug_backtrace()
function to ZE1.  as it's more-or-less the same
implementation as in ZE2 so it should be "fast and efficient"
enough for inclusion in 4.3 IMHO.

it has one extra feature over the ZE2 implementation by
giving some extra information if a method was called
using :: or -> (see the 'type' attribute in the array
returned by debug_backtrace).

zeev, andi one question: i had to comment line 1628 (just
apply the patch and see for yourself) to make the following
code work correctly (= show the class in the backtrace):

dump();
?>

(just uncomment line 1628 in the patched sources and see how
the output of debug_backtrace doesn't show the class-name for
this script any more)

i don't think that commenting this line will have any
side-effect as EG(object).ptr will be re-initialized in 1665
and i don't see any references to it in between.

i'd love to have this included in 4.3.0 and i think a lot of
people would be happy as well.

implementation:
to make this whole thing work i simply added the class_entry
to the execute_data and am pushing and popping it together
with (object).ptr.

if this patch gets accepted i'll add an php.ini seting so
that errors and warnings will optionally have the full
call-stack.


comments are welcome - especially from andi & zeev.
tc

PS: patch is against -HEAD

-- 
Thies C. Arnzten   -   Looking for all sorts of freelance work  -   just ask..
Whishlist: http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ/ref=wl_em_to


? ext/tca_prof
Index: Zend/zend_builtin_functions.c
===
RCS file: /repository/Zend/zend_builtin_functions.c,v
retrieving revision 1.118
diff -u -r1.118 zend_builtin_functions.c
--- Zend/zend_builtin_functions.c   12 Jun 2002 17:02:22 -  1.118
+++ Zend/zend_builtin_functions.c   16 Aug 2002 17:22:01 -
@@ -65,6 +65,7 @@
 static ZEND_FUNCTION(extension_loaded);
 static ZEND_FUNCTION(get_extension_funcs);
 static ZEND_FUNCTION(get_defined_constants);
+static ZEND_FUNCTION(debug_backtrace);
 #if ZEND_DEBUG
 static ZEND_FUNCTION(zend_test_func);
 #endif
@@ -116,6 +117,7 @@
ZEND_FE(extension_loaded,   NULL)
ZEND_FE(get_extension_funcs,NULL)
ZEND_FE(get_defined_constants,  NULL)
+   ZEND_FE(debug_backtrace,NULL)
 #if ZEND_DEBUG
ZEND_FE(zend_test_func, NULL)
 #endif
@@ -1133,6 +1135,69 @@
array_init(return_value);
zend_hash_apply_with_argument(EG(zend_constants), (apply_func_arg_t) 
add_constant_info, return_value TSRMLS_CC);
 }
+
+/* {{{ proto void debug_backtrace(void)
+   Prints out a backtrace */
+ZEND_FUNCTION(debug_backtrace)
+{
+   zend_execute_data *ptr;
+   int lineno;
+   char *function_name;
+   char *filename;
+   char *class_name;
+   zend_uint class_name_length;
+   zval *stack_frame;
+
+   ptr = EG(execute_data_ptr);
+
+   /* Skip debug_backtrace() itself */
+   ptr = ptr->prev_execute_data;
+   
+   array_init(return_value);
+
+   while (ptr) {
+   MAKE_STD_ZVAL(stack_frame);
+   array_init(stack_frame);
+
+
+/* if (ptr->object) {
+   class_name = Z_OBJCE(*ptr->object)->name;
+   class_name_length = Z_OBJCE(*ptr->object)->name_length;
+   }
+   if (ptr->function_state.function->common.scope) {
+   class_name = ptr->function_state.function->common.scope->name;
+   }
+*/
+   if (ptr->ce) {
+   add_assoc_string_ex(stack_frame, "type", sizeof("type"), "::", 
+1);
+   class_name = ptr->ce->name;
+   } else if (ptr->object.ptr) {
+   add_assoc_string_ex(stack_frame, "type", sizeof("type"), "->", 
+1);
+   class_name = ptr->object.ptr->value.obj.ce->name;
+
+   } else {
+   class_name = NULL;
+   }
+
+   function_name = ptr->function_state.function->common.function_name;
+   
+   filename = ptr->op_array->filename;
+   lineno = ptr->opline->lineno;
+
+   if (function_name) {
+   add_assoc_string_ex(stack_frame, "function", 
+sizeof("function"), function_name, 1);
+   }
+   if (class_name) {
+   add_assoc_string_ex(stack_frame, "class", sizeof("class"), 
+class_name, 1);
+   }
+   add_assoc_string_ex(stack_frame, "file", sizeof("file"), filename, 1);
+   add_assoc_long_ex(stack_frame, "line", sizeof("line"), lineno);
+   add_next_index_zval(return_value, stack_frame);
+
+   ptr = ptr->

Re: [PHP-DEV] 4.2.3

[Thies C. Arntzen]

On Sat, Aug 17, 2002 at 01:47:19PM +0300, Zeev Suraski wrote:
> I'd like to raise the option of releasing 4.2.3 again.  I believe that it 
> would be quite a while before 4.3.0 is out, and there are quite a few fixes 
> in the 4.2 branch that should make the userbase as soon as possible, 
> especially the Windows userbase.
> I think that releasing 4.2.3 can be done within approximately one week, 
> with one RC, barring unexpected surprises.
> Opinions?

ok by me. qa?

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

if noone objects i'm going to commit this to -HEAD (and we
can start discussing it then;-)

re,
tc

On Fri, Aug 16, 2002 at 07:39:59PM +0200, Thies C. Arntzen wrote:
> 
> hi,
> 
> this patch adds the extremely useful debug_backtrace()
> function to ZE1.  as it's more-or-less the same
> implementation as in ZE2 so it should be "fast and efficient"
> enough for inclusion in 4.3 IMHO.
> 
> it has one extra feature over the ZE2 implementation by
> giving some extra information if a method was called
> using :: or -> (see the 'type' attribute in the array
> returned by debug_backtrace).
> 
> zeev, andi one question: i had to comment line 1628 (just
> apply the patch and see for yourself) to make the following
> code work correctly (= show the class in the backtrace):
> 
>  class a {
>   function dump() {
>   var_dump(debug_backtrace());
>   }
> }
> 
> $a = new a;
> $a->dump();
> ?>
> 
> (just uncomment line 1628 in the patched sources and see how
> the output of debug_backtrace doesn't show the class-name for
> this script any more)
> 
> i don't think that commenting this line will have any
> side-effect as EG(object).ptr will be re-initialized in 1665
> and i don't see any references to it in between.
> 
> i'd love to have this included in 4.3.0 and i think a lot of
> people would be happy as well.
> 
> implementation:
> to make this whole thing work i simply added the class_entry
> to the execute_data and am pushing and popping it together
> with (object).ptr.
> 
> if this patch gets accepted i'll add an php.ini seting so
> that errors and warnings will optionally have the full
> call-stack.
> 
> 
> comments are welcome - especially from andi & zeev.
> tc
> 
> PS: patch is against -HEAD
> 
> -- 
> Thies C. Arnzten   -   Looking for all sorts of freelance work  -   just ask..
> Whishlist: http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ/ref=wl_em_to

> ? ext/tca_prof
> Index: Zend/zend_builtin_functions.c
> ===
> RCS file: /repository/Zend/zend_builtin_functions.c,v
> retrieving revision 1.118
> diff -u -r1.118 zend_builtin_functions.c
> --- Zend/zend_builtin_functions.c 12 Jun 2002 17:02:22 -  1.118
> +++ Zend/zend_builtin_functions.c 16 Aug 2002 17:22:01 -
> @@ -65,6 +65,7 @@
>  static ZEND_FUNCTION(extension_loaded);
>  static ZEND_FUNCTION(get_extension_funcs);
>  static ZEND_FUNCTION(get_defined_constants);
> +static ZEND_FUNCTION(debug_backtrace);
>  #if ZEND_DEBUG
>  static ZEND_FUNCTION(zend_test_func);
>  #endif
> @@ -116,6 +117,7 @@
>   ZEND_FE(extension_loaded,   NULL)
>   ZEND_FE(get_extension_funcs,NULL)
>   ZEND_FE(get_defined_constants,  NULL)
> + ZEND_FE(debug_backtrace,NULL)
>  #if ZEND_DEBUG
>   ZEND_FE(zend_test_func, NULL)
>  #endif
> @@ -1133,6 +1135,69 @@
>   array_init(return_value);
>   zend_hash_apply_with_argument(EG(zend_constants), (apply_func_arg_t) 
>add_constant_info, return_value TSRMLS_CC);
>  }
> +
> +/* {{{ proto void debug_backtrace(void)
> +   Prints out a backtrace */
> +ZEND_FUNCTION(debug_backtrace)
> +{
> + zend_execute_data *ptr;
> + int lineno;
> + char *function_name;
> + char *filename;
> + char *class_name;
> + zend_uint class_name_length;
> + zval *stack_frame;
> +
> + ptr = EG(execute_data_ptr);
> +
> + /* Skip debug_backtrace() itself */
> + ptr = ptr->prev_execute_data;
> + 
> + array_init(return_value);
> +
> + while (ptr) {
> + MAKE_STD_ZVAL(stack_frame);
> + array_init(stack_frame);
> +
> +
> +/*   if (ptr->object) {
> + class_name = Z_OBJCE(*ptr->object)->name;
> + class_name_length = Z_OBJCE(*ptr->object)->name_length;
> + }
> + if (ptr->function_state.function->common.scope) {
> + class_name = ptr->function_state.function->common.scope->name;
> + }
> +*/
> + if (ptr->ce) {
> + add_assoc_string_ex(stack_frame, "type", sizeof("type"), "::", 
>1);
> + class_name = ptr->ce->name;
> + } else if (ptr->object.ptr) {
> + add_assoc_string_ex(stack_fr

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

there is one tiny change that might destabelize the ZE1 - i
asked if you could take a look and see if you agree with
me that this change is actually *not* harmful.

i don't really see your point that having debug_backtrace
only available in ZE2 will bring more momentum to the ZE2
development. and not wanting a new (and btw very useful
feature) in ZE1 for that very reason is not good IMHO.

zeev, andi - have you had a *look* at the patch and do you see
any good reason not to have it in 4.3? i do not buy you "lets
only bring ZE2 forward" argument at all.

i'd love to hear more opinions on this.
tc

On Sun, Aug 18, 2002 at 06:40:35PM +0300, Andi Gutmans wrote:
> I also think we should make sure enough people have motivation to move to 
> ZE2. If not it'll be hard to push it out and we all know that it's a very 
> important step for PHP. As it is, there is still not enough momentum behind 
> it.
> Andi
> 
> At 05:38 PM 8/18/2002 +0300, Zeev Suraski wrote:
> >I said before - I prefer not having any changes in ZE1, for both stability 
> >reasons and also as a motivation to get ZE2 out the door more quickly.
> >
> >Zeev
> >
> >At 17:21 18/08/2002, Thies C. Arntzen wrote:
> >
> >>if noone objects i'm going to commit this to -HEAD (and we
> >>can start discussing it then;-)
> >>
> >>re,
> >>tc
> >>
> >>On Fri, Aug 16, 2002 at 07:39:59PM +0200, Thies C. Arntzen wrote:
> >>>
> >>> hi,
> >>>
> >>> this patch adds the extremely useful debug_backtrace()
> >>> function to ZE1.  as it's more-or-less the same
> >>> implementation as in ZE2 so it should be "fast and efficient"
> >>> enough for inclusion in 4.3 IMHO.
> >>>
> >>> it has one extra feature over the ZE2 implementation by
> >>> giving some extra information if a method was called
> >>> using :: or -> (see the 'type' attribute in the array
> >>> returned by debug_backtrace).
> >>>
> >>> zeev, andi one question: i had to comment line 1628 (just
> >>> apply the patch and see for yourself) to make the following
> >>> code work correctly (= show the class in the backtrace):
> >>>
> >>>  >>> class a {
> >>>   function dump() {
> >>>   var_dump(debug_backtrace());
> >>>   }
> >>> }
> >>>
> >>> $a = new a;
> >>> $a->dump();
> >>> ?>
> >>>
> >>> (just uncomment line 1628 in the patched sources and see how
> >>> the output of debug_backtrace doesn't show the class-name for
> >>> this script any more)
> >>>
> >>> i don't think that commenting this line will have any
> >>> side-effect as EG(object).ptr will be re-initialized in 1665
> >>> and i don't see any references to it in between.
> >>>
> >>> i'd love to have this included in 4.3.0 and i think a lot of
> >>> people would be happy as well.
> >>>
> >>> implementation:
> >>> to make this whole thing work i simply added the class_entry
> >>> to the execute_data and am pushing and popping it together
> >>> with (object).ptr.
> >>>
> >>> if this patch gets accepted i'll add an php.ini seting so
> >>> that errors and warnings will optionally have the full
> >>> call-stack.
> >>>
> >>>
> >>> comments are welcome - especially from andi & zeev.
> >>> tc
> >>>
> >>> PS: patch is against -HEAD
> >>>
> >>> --
> >>> Thies C. Arnzten   -   Looking for all sorts of freelance 
> >>work  -   just ask..
> >>> Whishlist: 
> >>http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ/ref=wl_em_to
> >>
> >>> ? ext/tca_prof
> >>> Index: Zend/zend_builtin_functions.c
> >>> ===
> >>> RCS file: /repository/Zend/zend_builtin_functions.c,v
> >>> retrieving revision 1.118
> >>> diff -u -r1.118 zend_builtin_functions.c
> >>> --- Zend/zend_builtin_functions.c 12 Jun 2002 17:02:22 
> >>-  1.118
> >>> +++ Zend/zend_builtin

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 08:19:52PM +0300, Zeev Suraski wrote:
> I haven't, because of the two reasons I mentioned.  There's nothing about 
> the specifics of the patch that can make me change my personal mind about 
> it...
> I understand you disagree with me about the momentum issue, so let's agree 
> to disagree.

so you're saying we effectifly stop working on improvements
for ZE1?

not sure if too many ppls will be happy to hear that whitout
even having a clear roadmap for ZE2..

please reconsider...

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 10:29:47AM -0700, Rasmus Lerdorf wrote:
> I don't think we should stop people from tweaking ZE1. ZE2 is probably
> more than a year away from realistically being available to a lot of
> people. It takes a while for people to upgrade, and many will skip the .0
> release.  If a few tweaks to ZE1 can eliminate peoples' motivation to move
> to ZE2, then why are you writing ZE2?  I obviously don't think that is the
> case as ZE2 has a number of features people have been asking for.

i (of course) agree with derick and rasmus. i'm all for
applying the patch as is. if zeev and andi don't want to
comment on it for their own reasons i cannot help them. if
the patch has a problem it'll be found very soon and it'll
be fixed.

if there is any *technical* reason why this patch is "not as
good" as the debug_backtrace that is in ZE2 - let me know.
otherwise i'll commit on monday.

re,
tc
> 
> -Rasmus
> 
> On Sun, 18 Aug 2002, Zeev Suraski wrote:
> 
> > I haven't, because of the two reasons I mentioned.  There's nothing about
> > the specifics of the patch that can make me change my personal mind about it...
> > I understand you disagree with me about the momentum issue, so let's agree
> > to disagree.
> >
> > Zeev
> >
> > At 20:12 18/08/2002, Thies C. Arntzen wrote:
> >
> > > there is one tiny change that might destabelize the ZE1 - i
> > > asked if you could take a look and see if you agree with
> > > me that this change is actually *not* harmful.
> > >
> > > i don't really see your point that having debug_backtrace
> > > only available in ZE2 will bring more momentum to the ZE2
> > > development. and not wanting a new (and btw very useful
> > > feature) in ZE1 for that very reason is not good IMHO.
> > >
> > > zeev, andi - have you had a *look* at the patch and do you see
> > > any good reason not to have it in 4.3? i do not buy you "lets
> > > only bring ZE2 forward" argument at all.
> > >
> > > i'd love to hear more opinions on this.
> > > tc
> > >
> > >On Sun, Aug 18, 2002 at 06:40:35PM +0300, Andi Gutmans wrote:
> > > > I also think we should make sure enough people have motivation to move to
> > > > ZE2. If not it'll be hard to push it out and we all know that it's a very
> > > > important step for PHP. As it is, there is still not enough momentum
> > > behind
> > > > it.
> > > > Andi
> > > >
> > > > At 05:38 PM 8/18/2002 +0300, Zeev Suraski wrote:
> > > > >I said before - I prefer not having any changes in ZE1, for both
> > > stability
> > > > >reasons and also as a motivation to get ZE2 out the door more quickly.
> > > > >
> > > > >Zeev
> > > > >
> > > > >At 17:21 18/08/2002, Thies C. Arntzen wrote:
> > > > >
> > > > >>if noone objects i'm going to commit this to -HEAD (and we
> > > > >>can start discussing it then;-)
> > > > >>
> > > > >>re,
> > > > >>tc


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 08:49:30PM +0300, Zeev Suraski wrote:
> At 20:40 18/08/2002, [EMAIL PROTECTED] wrote:
> >I'm not happy with that indeed. ZE1 is still the current version, and I
> >wouldn't see any reason to not extend it (or even backport things from
> >ZE2 as this patch is largely about).
> 
> Why not backport all the changes then?
> I'm -1 on introducing any new features in ZE1.  I think Andi is too.  If 
> everyone votes against us, you know, there are other people with commit 
> access, but it's a bit of a slap in the face, especially considering this 
> is Andi's code in the first place.

we _want_ to work together, right? atleast i want that. i
have pulled my hair many times for having a real-backtrace on
a production-site _without_ having to load an extension that
makes the whole site ~10% slower (sorry, derick)

you are slapping into the users face by saying, wait another
6 month for something that could be available as soon as 4.3.

BTW: the code we're talking about is neither magic nor very
complex. andi, sorry i you felt me stepping on your feet;-)

zeev, this discussion should be pure technical, any political
or personal things should be left off!

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 08:50:04PM +0300, Zeev Suraski wrote:
> At 20:24 18/08/2002, Thies C. Arntzen wrote:
> >On Sun, Aug 18, 2002 at 08:19:52PM +0300, Zeev Suraski wrote:
> >> I haven't, because of the two reasons I mentioned.  There's nothing about
> >> the specifics of the patch that can make me change my personal mind about
> >> it...
> >> I understand you disagree with me about the momentum issue, so let's 
> >agree
> >> to disagree.
> >
> >so you're saying we effectifly stop working on improvements
> >for ZE1?
> 
> Yep.

so - cool, you (z&a) stopped working on it. does that mean
it's now written in stone and nobody is allowed to touch it?

i have asked very nicely if you could review a patch i've
written. i have cc'ed you and andi as you are the authors of
the engine. - no reply - 

the reply i got after pinging again had _no_ technical
background whatsoever. i have asked on php-dev and not
php-tellmeyoufeelingsaboutthefuture.

this is more than a little frustrating for me and i'm sure
not too many ppls will be happy about your "desupport notice"
for ZE1.

> 
> >not sure if too many ppls will be happy to hear that whitout
> >even having a clear roadmap for ZE2..
> 
> We have a pretty clear roadmap for ZE2 AFAIK.  We're currently lingering 
> for no good reason.

apache 2.0 - does that ring a bell?

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 09:00:25PM +0300, Zeev Suraski wrote:
> At 20:54 18/08/2002, Thies C. Arntzen wrote:
> >BTW: the code we're talking about is neither magic nor very
> >complex. andi, sorry i you felt me stepping on your feet;-)
> 
> And yet you took it from ZE2 a couple of months after it was written, as 
> opposed to two years ago when ZE1 was already out?  Come on, Thies, 
> sometimes knowing which algorithm to use and where to put the two lines of 
> code is the complexity, as it is in this case.

i am working on a zend-extension that needs to know the real
current backtrace. you wrote the ze-extension interface, and
you should know that it's *very*, *very* hard to find the
real callstack from within an extension (all extensions i'm
aware of have do it wrong).

after fiddling with it for a while i looked at the stuff andi
did and found that it can be apllied mostly (there _is_ one
difference) to ZE1, what's wrong with that? do i want credits
for it? NO. do i think this feature will help me and others?
YES.

> 
> >zeev, this discussion should be pure technical, any political
> >or personal things should be left off!
> 
> I have two reasons, one technical (stability) and one which you may call 
> political (ZE2).  I don't see anything wrong with taking 'political' 
> reasons into account.  PHP is a big thing today, we can't treat it in the 
> same way that we treated it five years ago.

you told me that you didn't even look into the patch. so -no-
you have no technical reason except if you think i'm stupid.

"your" political reason has no standing in my opinion.

> 
> Replying to Rasmus' concern - of course we're not afraid that this tiny 
> patch will 'eliminate' the motivation of people to move.  It's the state of 
> mind of php-dev that I'm afraid of.  Much like your perception is that 
> we're more than a year away from a usable version, and Thies's perception 
> that we have no roadmap for ZE2 - you can only imagine what other, less 
> core developers have in mind.  We need to get going with ZE2, and yes, 
> holding on and keeping goodies for the new version are a way of doing 
  ^^ you can do that in
  closed-source, commercial software. trying to do that in
  opensource will drive people away from you...

 
> it.  I did that in lots of features in PHP 4, and frankly, I think it's 
> very lucky that I did, as the transition from PHP 3 to 4 was VERY 
> successful.  Imagine if we still had to fix PHP 3 bugs on a daily basis.

i do remember countless hours that i put into the transition
from PHP 3 to PHP 4 during that time i became a member of the
"PHP Group" - but what has that to do with debug_backtrace()?

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 08:18:40PM +0200, [EMAIL PROTECTED] wrote:
> On Sun, 18 Aug 2002, Thies C. Arntzen wrote:
> 
> > we _want_ to work together, right? atleast i want that. i
> > have pulled my hair many times for having a real-backtrace on
> > a production-site _without_ having to load an extension that
> > makes the whole site ~10% slower (sorry, derick)
> 
> It was not written with speed in mind, so I think it's pretty good that 
> it's only 10% slower :)

it can't be much faster - i've beed down that path.

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 01:06:47PM -0500, Richard Thomas wrote:
> Zeev makes a very very good point here..
> 
> What is the point of backporting everything into 4.3, There is no real
> point. PHP needs to move forward with new and improved.. Not spending
> its time going no where, and trying to improve on going no where.

richard,
you are missing the point here, the time is already spent. it
has been backported. why not accept the patch?

> 
> With ZE2 being the current goal the only thing that should go into ZE1
> would be security/bug's that require fixing.. The only goal for ZE1
> should be keeping it stable/safe.. Not making it better.

i disagree.
tc


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 09:26:45PM +0300, Zeev Suraski wrote:
> At 21:15 18/08/2002, Thies C. Arntzen wrote:
> >On Sun, Aug 18, 2002 at 09:00:25PM +0300, Zeev Suraski wrote:
> >> At 20:54 18/08/2002, Thies C. Arntzen wrote:
> >> >BTW: the code we're talking about is neither magic nor very
> >> >complex. andi, sorry i you felt me stepping on your feet;-)
> >>
> >> And yet you took it from ZE2 a couple of months after it was written, as
> >> opposed to two years ago when ZE1 was already out?  Come on, Thies,
> >> sometimes knowing which algorithm to use and where to put the two lines 
> >of
> >> code is the complexity, as it is in this case.
> >
> >i am working on a zend-extension that needs to know the real
> >current backtrace. you wrote the ze-extension interface, and
> >you should know that it's *very*, *very* hard to find the
> >real callstack from within an extension (all extensions i'm
> >aware of have do it wrong).
> 
> It may sound like a product pitch but it really isn't - did you take a look 
> at the way the Zend Studio displays stack traces?  AFAIK, it's absolutely 
> accurate, and it doesn't do any magic.  I'm not aware of any problems 
> getting the stack trace right with the extension interface.  I can even 
> help you with that.

look at the opcodes for:

a(b(c()));

function a() {}
function b() {}
function c() {}

and tell me which function is called from which scope. unless
you know something i dont youll see 
a()
b()
c()

which is wrong as the correct call-order is 
c()
b()
a()


> 
> >after fiddling with it for a while i looked at the stuff andi
> >did and found that it can be apllied mostly (there _is_ one
> >difference) to ZE1, what's wrong with that? do i want credits
> >for it? NO. do i think this feature will help me and others?
> >YES.
> 
> I didn't think you wanted credit for it, that's obviously not the 
> issue.  The two issues I did mention, coupled with the fact that Andi is 
> the one who wrote the code in the first place, are the issue, IMHO.
> 
> >you told me that you didn't even look into the patch. so -no-
> >you have no technical reason except if you think i'm stupid.
> 
> Uhm no.  Touching a delicate portion of execute() is dangerous no matter 
> what.  If it's for adding a new feature, then in my humble opinion, it is 
> not worth it at this point.

we have soo many ppls currently working again on -HEAD and
we'll have a full QA cycle before 4.3. i don't think this
feature will cost us anything that can't be paid for with a
single dime.

> 
> >"your" political reason has no standing in my opinion.
> 
> To each his own.
> 
> >  ^^ you can do that in
> >  closed-source, commercial software. trying to do that in
> >  opensource will drive people away from you...
> 
> As it did with PHP 4?  Commercial software and opensource software have 
> lots of things in common, and encouraging people to migrate to the newest 
> version is one of those things.  If you don't, you get into a support 
> nightmare.  It's as simple as that.
> 
> >
> >> it.  I did that in lots of features in PHP 4, and frankly, I think it's
> >> very lucky that I did, as the transition from PHP 3 to 4 was VERY
> >> successful.  Imagine if we still had to fix PHP 3 bugs on a daily basis.
> >
> >i do remember countless hours that i put into the transition
> >from PHP 3 to PHP 4 during that time i became a member of the
> >"PHP Group" - but what has that to do with debug_backtrace()?
> 
> Nothing specific, it has to do with new features.  I added lots of new 
> features that could be backported to PHP 3, when PHP 3 was a hell of a lot 
> more popular than 4, when 4 was really just a beta.  Forget my code.  The 
> session module could be ported  back to PHP 3 with almost no changes, why 
> wasn't it done?  And you know, session functionality is something useful to 
> literally everyone, and is much more important than a backtrace.

you're comparing bytes and apples here. PHP4 and PHP3 were
sooo different. and i recall that you have backported the new
memory zend memory-manager to php3, didn't you?

> 
> If you want it so much and need it so much and are so furious about it, 
> then whatever, backport it.  Let it be noted that I firmly object, and that 
> Andi objected as well (not sure how firmly :)  Let it be also noted that I 
> will firmly object to further backports of new features in the future.

i think this might be the only feature that justifies
backporting as: 
a) the backport is minimal (and already done)
b) the feature is very useful for anyone that develops with
php (which is our primary audience)

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Sun, Aug 18, 2002 at 11:48:03PM +0300, Andi Gutmans wrote:
> At 07:50 PM 8/18/2002 +0200, Thies C. Arntzen wrote:
> >On Sun, Aug 18, 2002 at 10:29:47AM -0700, Rasmus Lerdorf wrote:
> >> I don't think we should stop people from tweaking ZE1. ZE2 is probably
> >> more than a year away from realistically being available to a lot of
> >> people. It takes a while for people to upgrade, and many will skip the .0
> >> release.  If a few tweaks to ZE1 can eliminate peoples' motivation to 
> >move
> >> to ZE2, then why are you writing ZE2?  I obviously don't think that is 
> >the
> >> case as ZE2 has a number of features people have been asking for.
> >
> >i (of course) agree with derick and rasmus. i'm all for
> >applying the patch as is. if zeev and andi don't want to
> >comment on it for their own reasons i cannot help them. if
> >the patch has a problem it'll be found very soon and it'll
> >be fixed.
> 
> This isn't a conspiracy but I just completely forgot about your Email. 
> Obviously if it is decided that this patch goes into Engine 1 I will look 
> it over. The last thing I'd do was to allow a buggy patch to enter the 
> Engine.

andi,

i'd love if you could comment on the commenting out line 1626
in the unpatched zend_execute which is needed to have a
correct backtrace in some situations. EX(object).ptr will
always be correctly reinitialized around line 1662 in the
unpatched zend_execute so i believe line 1626 in unneded.
> 
> 
> >if there is any *technical* reason why this patch is "not as
> >good" as the debug_backtrace that is in ZE2 - let me know.
> >otherwise i'll commit on monday.
> 
> I don't think that there are any big technical reasons not to include the 
> patch although it might be a bit buggy though as it hasn't been tested very 
> extensively.

i fully agree. 

> 
> I do think you guys should consider the psychological aspects of starting 
> to back port my patches from Engine 2.

as said in am the course of discussion, debug_backtrace is
(so far) the only thing really worth backporting from ZE2 as
it's a small piece of code that really makes live easier for
script-developers.


> I personally think that the ZE2 is essential for PHP to prosper in the next 
> few years. The only way it can be pushed is if not only Zeev and I but 
> other people in the community help push it too. It was mentioned that there 
> are a couple of things still missing. I can sum it up that the two main 
> features which are missing are some inheritence problems with nested 
> classes, private methods and a delegation mechanism which was discussed on 
> engine2 for which came up with a pretty decent way of doing which stays 
> with the PHP spirit. These things will be implemented and there is no 
> reason to wait until they are fully implemented in order to start pushing 
> things a bit more. I started with a couple of alpha's and I definitely want 
> to go for another one soon as I fixed some bugs.
> 
> In the same way we didn't back port some ideas from PHP 4 to PHP 3 I think 
> it's best not to do it now. Because in the end, once we (php-dev) 
> transitions to ZE2 our support will naturally start shifting more and more 
> towards the latest versions (the same as it did in the PHP 3 -> PHP 4 
> transition). After sometime people on php-dev just won't feel like working 
> on old stuff anymore. Therefore, I think we should make the benefit of 
> transition to ZE2 as great as possible so that people migrate.
> As to the comparison to Apache 2 I think you're far off. The PHP 3 -> PHP 4 
> transition was much smoother than that and the ZE1 -> ZE2 transition isn't 
> even between rewrites but just improvements over the old stable version. 
> Once a significant amount of people use it I think it'll take 2-3 months to 
> iron out the bugs.

remember, we are not talking about a backport of real new
functionality, nor a new language feature. we're talking
about adding a very useful feature for developers.

my apache 2.0 thing got misinterpreted a bit - let me
clearify: apache2.0 is ready, it works and it's even better
than 1.3 (the httpd itself). but ppls don't upgrade all
threir servers immediatly. as rasmus mentioned, the same
thing will happen once PHP5 comes out. it won't be widely
used and available to everybody the day it comes out.

as for debug_backtrace() (an _only_ debug_backtrace()) i
think this is such a cool thing to have and i whished i had
it when there was PHP3. i do write large applications, and
it's sometimes very hard to find out, what's going on. c'mon
how often do you type "bt" in gdb?

re,
tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Mon, Aug 19, 2002 at 11:45:30AM +0300, Zeev Suraski wrote:
> 
> How often do you call a function that gives you your current backtrace in 
> C?  In my many years of C experience, I would have to say that the accurate 
> answer is -0- times.  You really should compare apples with apples...

you often said in the past that you don't write php-apps, you
write php. i do write php-apps, and debug_backtrace() is one
of the most useful features if your app reaches an
"unexpected failure" (= likely a bug). right now i load some
zend-extension on my devel boxes - but (as you know), the
unexpected often only happens on productions systems. my
production systems are soo loaded that i cannot afford to
load the zend-extension on there. so post-mortem analysis is
much harder there, and you know how hard it sometimes is to
reporduce bugs (remember how often i spend hours just to sent
you guys the shortest-possible testcase for bugs?)

but - in a way you are right, i'm comparing apples and pies.
the debug_backtrace() for me is like calling abort() in my
c-code to be able to inspect the core-file and see where
things went wrong.

anyway, i don't thing we are discussing the usefullness of
debug_backtrace() here.

i think andi will look over the one critical line of the
patch - if he agrees that this change is "ok", i will go
ahead and commit.

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Thies C. Arntzen]

On Tue, Aug 20, 2002 at 06:12:19PM +0300, Zeev Suraski wrote:
>
> You won't upgrade even in a year's time, or even 1.5 year's time, when all 
> new features, and at some point, security fixes, are available for 
> it?  That is my point, Brad, exactly.  We barely have enough manpower to 
> maintain one version, you seriously think we can maintain two?  Every 
> carrot to encourage migration, even if it's a minicarrot, should be used.
> By the way, if you really don't intend to upgrade to take advantage of new 
> features and fixes, I'm willing to bet that these boxes are static boxes 
> with legacy apps that won't include active development.  As the feature in 
> question is debugging/development related, I can't see how it will be 
> useful in that setup.

i really have to say that this feature is _extremly_
helpful on production-machines, as certain bugs simply
don't appear while developing an application. beeing able to
have more information what when wrong (and who made it go
wrong) on a produnction system (where performance doesn't
allow loading eg dericks xdebug) is just such a nice thing.

don't you think you overestimate the importance of
debug_backtrace() for the ZE2 a bit? ZE2 will stand by it's
own, and if you and andi didn't had this cool idea on how to
implement debug_backtrace() in an efficient way, we'd tell
users in 3 years that it's not possible to have it without
having a major performance hit.

i'm atleast happy that the real reason for your dislike is
now very clear and has been said by you and andy -> it's the
'carrot for the donkey'.


current situation is:
- it's there (invented by you and andi for ZE2)
- it's backported and works as well in ZE1
- you don't want it in ZE1 as you want to keep it as your
  "golden bullet" to make non-OO people switch to ZE2
- ZE2 won't be available for some time
- there is no decent/working alternative for production
  system to allow post-mortem analysys. 
- by showing how-pissed you would be if i committed and
  knowing that i respect you guys a lot you are vetoing out a
  cool feature for all people that have to write and deploy
  php apps *today*. 
- by taking momentum from PHP4/ZE1 development you will _not_
  build more momentum for PHP5/ZE2 - the opposite is more
  than true.
- you are pissed 
- i am pissed

the only guilt i have is that i've shown the kids the toy -
and you're not allowing it away. and i'm not even guilty of that! i
i was full of good intention when looking into this.


i will continue to advocte for inclusion of the patch, you'll
have to continue telling people "no, this sweet carrot is
only for the brave somewhen early next year!"

doesn't that feel strange?
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] ext OCI8 again

[Thies C. Arntzen]

On Thu, Aug 22, 2002 at 02:06:51PM +0200, [EMAIL PROTECTED] wrote:
> Hi everyone
> 
> I am in the process of rewriting a few parts of the oci ext,
> mainly the createn/init of OCIEnv. This is an extremly
> important step in order to be able to support multiple nls's
> (character sets etc.) on the same server in a shared
> environment.
> 
> just to understand it:
> 
> as it seems, OCI(pEnv) is filled once at MINIT, which means
> that all sessions share the nls environment settings. if I
> change the initialization to be done upon every connection
> start, this would ultimatly lead to chaos since all running
> sessions (or requests) share the same env.

what i would do is move the env into the oci_session and add
another parameter to oci[p|n]logon() - the NLS setting for
this connection. that way it shouldn't become a mess;-)

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] #18640: compilation with Oracle fails on Tru64

[Thies C. Arntzen]

On Mon, Sep 09, 2002 at 07:46:00PM +0200, Sebastian Nohn wrote:
> > -Original Message-
> > From: Michael Mauch [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, September 09, 2002 6:52 PM
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-DEV] [PATCH] #18640: compilation with Oracle fails on
> > Tru64
> > 
> > Can somebody please add this? If this is not the right way to send a
> > patch, please tell me.
> 
> +1 on adding this to cvs. Thies, what's your opinion on this one?
go ahead - if you have the karma, else ask again and i'll
commit.

tc
 

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
Whishlist:  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PREAD yet again

[Thies C. Arntzen]

On Thu, Sep 19, 2002 at 08:30:06AM -0400, Dan Kalowsky wrote:
> Hello list,
> 
> In PHP 4.2.3 I removed the PREAD functionality from the session module 
> due to a bug in the glibc libraries on non-x86 machines.  In CVS HEAD 
> Sascha has re-added it using some tests.  Unfortunately it seems that 
> these tests don't seem to work well, and still cause the session module 
> not to work.

what arch?

i'm all for fixing this as using the p*() functions is
slighly faster. which is a GoodThing(tm)

tc
> 
> If this isn't fixed before the 4.3 RC process I'd like to ask that this 
> be removed once again until it can be further tested.
> 
> >---<
> Dan Kalowsky"Tonight I think I'll walk alone,
> http://www.deadmime.org/~dankI'll find myself as I go home"
> [EMAIL PROTECTED]- "Temptation",
> [EMAIL PROTECTED]  New Order
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
Whishlist:  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: php/embed (build system changes)

[Thies C. Arntzen]

On Tue, Oct 01, 2002 at 10:38:54PM +0200, Sascha Schumann wrote:
> On Tue, 1 Oct 2002, Andrei Zmievski wrote:
> 
> > On Tue, 01 Oct 2002, Sascha Schumann wrote:
> > > Fortunately, I have some spare time and look forward to
> > > purge some of the cruft which has assembled since the CLI
> > > support was added.  By extending the problem domain, we can
> > > simplify and abstract a number of cases in the build system.
> > > That will be a lot of fun.
> >
> > Does this mean that you want to delay 4.3.0?
> 
> Nope, this is 4.3.1 material.

you mean 4.4? our new rules says to merge only fixes into
a release branch. 

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Feature ./ correction to design flaw request

[Thies C. Arntzen]

On Thu, Oct 10, 2002 at 09:52:50PM +0100, Nick Lindridge wrote:
> Hello,
> 
> Although most globals are correctly handled in PHP for thread safety, the
> zend_execute and zend_compile_file hooks are not given slots in any TS
> memory.
> 
> It would be beneficial to correctly give these globals TS slots.

why would one want to have different executors/compilers in
different threads?

i can see that there might be a race if an extension
sets/changes zend_execute and/or zend_compile_file while
another thread is serving pages. is that your problem?

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] OCI extension help offer

[Thies C. Arntzen]

On Tue, Oct 15, 2002 at 01:51:29PM +0200, Maxim Maletsky wrote:
> 
> Guys, a few month ago, I have been trying to offer some of my help for
> developing Oracle 9i extension, or in anyway, to improve the existing
> PHP/Oracle functionality.
> 
> original posts are here: 
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=aiquvp%2412e7%241%40FreeBSD.csie.NCTU.edu.tw&rnum=120&prev=/groups%3Fq%3DOCI8%2Bgroup:mailing.www.php-dev%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd%26start%3D110%26sa%3DN)
> 
> 
> Having put onto the real-life test OCI8 extensions for the Italian
> Government framework, I noticed many serious imperfections with the
> current OCI8 extension.
> 
> I personally think that Oracle is very important for PHP's future, and
> that current extension is not very perfect and up to date.
> 
> Please let me know if you are interested in my contributions regarding
> it.

very cool, what do you want to contribute?

re,
tc
> 
> -- 
> Maxim Maletsky
> [EMAIL PROTECTED]
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] OCI extension help offer

[Thies C. Arntzen]

On Tue, Oct 15, 2002 at 05:41:59PM +0200, [EMAIL PROTECTED] wrote:
> 
> Thanks, Andi.
> 
> yeah, I will wait for Thies to reply to me. We have sort of a started
> this discussion with him before, so hopefully he will join into this one.
> 
> My main concerns about OCI8 are the followings ones. Some of them are
> related to the opverall idea of PHP-DB usage, some to the actual
> performance and some to the missing functionalities. Some, might be
> bogus or hardly accomplisheble. Here's what I think:
> 
> 1. Datatype support. Right now, OCI8 only supports string and integer
> datatypes binded via PLSQL. It would be great being able to use all the
> remaining ones like booleans and dates, the other, incompatible onces
> might need to be translated into PHP's way so they can be used within
> PHP. Main problem of this is that, tipically, DBAs would grant the
> access via PLSQL (stored procedures) to a various number of clients,
> applications and langueages. Since, PHP does not funny support PLSQL,
> interfacing Oracle via PHP not having to change stored procedures is
> very limited.

cool. how do you want to do this? php only has support for
strings and numbers. so we would have to add PHP resources
for all the other types.

> 
> 2. XMLTYPE. This is new since Oracle 9.2. Will all the XML fever of
> today, wouldn't it be possible to add some extra compatibility for it to
> stipulate Oracle users using PHP? Always if this is dopable and logical.

haven't really read the oracle-docs on that one. could you
give me a doc-link for this?

> 
> 3. Record type from Stored Procedures. (similar to #1) This is a VERY
> BIG limitation.  It is, probably, the 50% of the reason why PHP is not
> used much with Oracle.  Most programming languages can retrieve RECORD
> type from stored procs. and use it as arrays of data (like plain SQL
> records return). PHP fails on it, it only allows you to return the
> cursor, and for that you need to modify (descresing so performance) the
> stored procedures directly. At my work, (Italian Government) a datadase
> had over 500 stored procedures used via other programming languages. To
> migrate onto PHP, these all had to be changed and the backwards
> compatibility to the previous programming language was completely lost.
> It's a big issue.

yep, agreed. even though i don't use it myself i think it
would be great if we could support them. have you had a look
at the collections stuff in oci8.c?

> 
> 4. OCI8 module naming conventions. How come OCI module is named OCI8
> (specifically)? I think this makes it
> hard for many to believe that it can fully be compatible with upcoming
> releases of Oracle. Lots of businesses count a lot on application life-times
> and, seeing '8' (or so would be with '9') makes management feel that they
> might not be able to upgrade their expensive Oracle licences till PHP comes
> up with some newer number on the extension name. Which, in our case means
> changing the whole extension and, I really don't think we would be doing
> that too often. I personaly would see Oracle extension better with one only
> generic name like OCI, ora, oracle or whatever but not version-labeled.
> This could also help us keeping the OCI8 intact while adding newer
> changes.

the functions are all called oci_*(). the name of the
extension is not really visible (unless you "configure" php).
i don't see this as an issue at all,, but -sure- we could
rename the extension.


> 
> 5. Functions are called OCI .* I do well know what it refers to, but
> this is only because I learned the original oci.h API. Wouldn't itbe more
> standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions
> ect? OCI make it a bit confusing, I always heard from my co-workers.
> Besides, this can also be a great input for newer Oracle's updates.

see #4.

> 
> Here's one of the sample bugs that can be occuring while continuing the
> current OCI8 extension with Oracle 9 and so on...
> 
> http://bugs.php.net/bug.php?id=18758

that one should be easy to fix - looking at it right now.
> 
> Hope, Thies and the rest of Dev Group can comment on my thought, and try
> to think of a way improving PHP's Oracle support so we can start working
> on it.  Btw, I do not have a karma for php4, so keep that in mind :) 

you have karma now.

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: OCI extension help offer

[Thies C. Arntzen]

On Wed, Oct 16, 2002 at 09:40:01AM +0900, Maxim Maletsky wrote:
> "Sebastian Nohn" <[EMAIL PROTECTED]> writes: 
> 
> >>5. Functions are called OCI .* I do well know what it refers to, but
> >>this is only because I learned the original oci.h API. Wouldn't itbe more
> >>standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions
> >>ect? OCI make it a bit confusing, I always heard from my co-workers.
> >>Besides, this can also be a great input for newer Oracle's updates.
> >
> >This is mainly because there are Oracle-funktions and OCI-functions (there
> >is a difference), and i like the OCI-thing very much, it's much easier and
> >faster to type than oracle ;)
> 
> Well, yes, OCI* functions look pretty geek, indeed, they are very similar 
> (if not identic, in some its parts) to the actual OCI API. 
> 
> But, this naming convention is way not optimal, is limited 
> functionality-wise and, last but not least, it is far not PHP's standard 
> naming convention for the database extensions. 
> 
> In fact, if you'll look into PHP standards specifications (look in CVS: 
> http://cvs.php.net/co.php/php4/CODING_STANDARDS?login=2&r=1.23) you are 
> encoraged using a certain style for calling your functions, especially 
> those of databases since these mostly do the same things. 
> 
> What I meant was, while to access a mySQL database you use mysql_connect(), 
> for PostgreSQL pg_connect() and for Sybase sybase_connect() question stays: 
> why function to connect to Oracle be called OCILogon()? Wouldn't it be 
> better called oracle_connect()? that is how som other programming languages 
> call it. 
> 
> It is not an exaggeration to say that, some programmers are actually making 
> their own functions named this very way so they can easier interact with 
> the Oracle database using their mySQL's (or whatever) habbits because OCI 
> gets them confused. I kind of followed this question within the PHP-Oracle 
> developers I met. 
> 
> For now, we have ora_* and OCI* functions. These are, as long as I 
> understand, used for Oracle v6.* and Oracle v8 (the last one is also 90% 
> compatible with v9). Yet, this shouldn't mean that there is no need for a 
> standarized set of functions like oracle_* with mapped/intuitive 
> functionalities like most of the DBs PHP that supports AND as compatible 
> between Oracle versions as possible. 

the ora_ extension uses the pre oracle8 api. if you need to
compile with oracle7 libraries you have to use the ora_*()
functions.

if you have libs >= oracle8 installed use the oci*()
functions. they will allow you to connect to oracle servers
running from version 7 till 9 (currently). the oci8
extension is btw 100% compatible with oracle9 - what do you
mean by saying 90%?


> 
> Only this way, one could firmly admit that PHP fully supports Oracle 
> database. 

hmm, i really don't know what you are talking about. the PHP
project (like all OpenSource projects i know of) does not
formally "certify" itself for certyin 3rd party libraries and
systems..

> 
> Those are my ideas for the Oracle extension. 
> 
> At this point, some new questions arised in my head: 
> 
> 1. Is ora_* extension (ext/oracle) still maintained and ported 
> compatibility-wise to the versions Oracle newer v6 or, for these are OCI8 
> extensions? If so, then this should mean that ora_* functions are limited 
> to version 6 only, if not deprecated at all. Am I correct, or missed the 
> point? If I guessed, then  what was the need for OCI8 extyension at all? 
> Why ora_* could not be continued? I still haven't found it out. 

read above.

> 
> 2. What costs merging the two extensions (ora_* and OCI8) in one (oracle_* 
> ?) that fully supports both 6*, 8* and 9* versions of Oracle and remains 
> the only one to be used (as well as maintained, debugged) in the feature? 

that would make no sense whatsoever, oci* has all that ora*
has, we could drop he oracle extension, but then we'd make
all the ppls unhappy that use it. (and may depend on it: see
above)
   
> 
> 3. Still, related to question 2: Wouldn't it be safe enough, if not rather 
> strategically clever to introuduce the oracle_* new functions as a new 
> unified extension for Oracle in all its versions within PHP 5? Considering, 
> that we are still at the planning stage of its development release? 

you mean renaming the oci8 extension - could be done... but i
personally see no pressing reason for doing so.

> 
> Hope to see someone to anser, commenting my thoughts on this. I am very 
> much willing contributing to the PHP's Oracle support development. 

that always appreciated. wher do you want to start?
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: [PHP-DEV] OCI extension help offer

[Thies C. Arntzen]

On Wed, Oct 16, 2002 at 10:22:04AM +0200, [EMAIL PROTECTED] wrote:
> I'm sure glad this in the headlines again ;-)
> 
> As Thies knows, I already proposed another important change,
> which is supporting multiple character sets. This is very
> important on shared web platforms, and I have experienced the
> trouble that arises from the way the oci ext treats the session
> environment (-> as a global one).  Oracle 9i offers some
> functions which help out from this dilemma, and I have changed
> the existing oci ext to support them. The most important change
> (from a user's viewpoint) is that OCILogon has an optional
> forth parameter, the character set, so an connection looks like
> this:
> 
> OCILogon($user,$pass,$tnsname,"WE8ISO8859P1");
> 
> Ok, I know this isn't ideal, since OCILogon already has an
> optional parameter, but maybe people can set $tnsname to false
> if they want to use the default one (ORACLE_SID) and use a
> specific character set? Anyway, my code works, and is already
> being used in a relativly big production environment.
> 
> >From a developers viewpoint what I mainly did was follow Thies' proposal and put 
>the environment struct in the session struct, and use the global env only for init 
>work. Then I decode the character set parameter (if it is omitted, the NLS_LANG 
>setting or Oracle default will be used) and use it in open_session. Voila, Oracle 
>takes care of the rest.
> 
> Works better than I thought :-). The only thing I need to do
> now is to add a compile-time decision on whether Ora9i
> libraries are found or not, and then to make this functionality
> available depending on the version. If anyone's interested I
> can send a patch.. As for the proposed name changes, IMHO it
> doesn't make that much of a sense, 1. since existing apps would
> have to be rewritten, and 2. there is absolutely zero
> effectiveness in merging the ora_ and OCI extensions, which
> differ greatly, into one. I think that would result in a mess
> or a big rewrite..

i'd love to see that patch integrated! can you send it to me?

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] OCI extension help offer

[Thies C. Arntzen]

On Wed, Oct 16, 2002 at 11:24:24AM +0200, Maxim Maletsky wrote:
> 
> any OCIParse and set the charset. This would be:
> 
> 1. more flexible
> 2. would exclude non-authentication functionality with OCILogon
> 3. easier to find for a user

adding the charset to the logon call is how "the others" do
it.

we could make the oracle env-handle visible to userspace, but
that would make using the beast more complex. 

adding it to the parse state makes little sense. as this is
not where it's done inside oracle.
>  
> 
> Wouldn't it be better, though? Yes, perhaps it would be a big rewrite,
> but it would definitely create an actual Oracle extension, not
> two version-specific ones. Really, it is confusing.
> 
> Try imagine a similar situation:
> 
> Whoever pays Oracle license is planning something big and costly. A such
> "user" would have no much trouble paying also for Java or ASP, that
> support Oracle pretty well, but, should the corp. prefer PHP, they'd
> consider this more than once.
> 
> This is because they would be soon confused about how things are working
> between PHP and Oracle, what Oracle versions are supported and for how
> long...  Then, automatically (in some heads) answer arises: "Yeah, PHP
> is Open Source, it won't support well commercial third parties...".
> 
> That is why I think that unifying Oracle into something that looks and
> works just as other Open Source DBs can help PHP (5?) gain better trust
> and confidence from middle-large projects worldwide.

we are talking about a legacy, more-or-less unsupported
version of oracle here (Oracle7 is no longer supported IIRC).
wasting any brain cyles for that will not bring us forward.
i'd love to see ext/oracle in PECL and slowly fade out.
everything else is not really an option INHO.

oci8 is the way to go -

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] OCI extension help offer

[Thies C. Arntzen]

On Wed, Oct 16, 2002 at 03:15:36PM +0200, Maxim Maletsky wrote:
> 
> 
> <[EMAIL PROTECTED]> wrote... :
> 
> > [EMAIL PROTECTED] schrieb am 16.10.02 14:27:35:
> > > 
> > > I think, at this point, it is up to Thies to review the patch.
> > > 
> > 
> > I hope he's not too harsh on it ;-), since this code is certainly *not*
> > ready for merging into the cvs tree. Meaning: it merges perfectly, but
> > doesn't compile correctly on Oracle 8i systems, only on 9i -> as I said,
> > this is still on my TODO list.
> 
> Then, it should remain a patch and not a part of the distribution.
> Unless, it can compile safely with Oracle 8. Still, up to Thies.

lets review it first - i'm sure we can find a way of adding
it to CVS.

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Re: [PHP-DEV] OCI extension help offer

[Thies C. Arntzen]

On Wed, Oct 16, 2002 at 10:26:46AM +0200, [EMAIL PROTECTED] wrote:
> Oh, and just to be clear about it: I am absolutely positive on
> a completely new (perhaps unified) extension for PHP 5, and
> would gladly participate.

hmm, sure - why not. we could start to brainstoorm about that
and decide if we need to rewrite or just add to what's there.

what are your plans, what features do you want to see?

i have things like failover and connection pooling (for
threaded servers) that i'd like to see in the future.

re,
tc




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] parse_url is not BC to 4.2.

[Thies C. Arntzen]

HEAD doesnt do parse_url("file:/tmp/bla") any more. (you need
to have 2 slahes after file: to make it work).

i really think we should allow the single-slash syntax again!

re,
    tc

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: OCI extension - OCIQuery() ?

[Thies C. Arntzen]

On Thu, Oct 17, 2002 at 01:36:26PM +0200, Maxim Maletsky wrote:
> 
> "Thies C. Arntzen" <[EMAIL PROTECTED]> wrote... :
> 
> > > Hope to see someone to anser, commenting my thoughts on this. I am very 
> > > much willing contributing to the PHP's Oracle support development. 
> > 
> > that always appreciated. wher do you want to start?
> > tc
> 
> 
> Thies, what do you thik of adding an OCIQuery function?
> 
> e.g: 
> 
>  
>   $query   = "SELECT to_char(sysdate) FROM dual";
> 
>   // this:
>   $stmt= OCIParse($conn, $query);
>   $result  = OCIExecute($stmt, OCI_DEFAULT);
> 
> 
>   // can be this:
>   $result  = OCIQuery($conn, $query, OCI_DEFAULT);
> 
> ?>
> 
> It could be a nice shortcut for those who use this combo always together
> and, plus, it would be a very elementary thing to implement.
> 
> What do you think of it?
> 
> I could start from this one, to warm up :) It's been I while I thought
> OCIQuery() could have been implemented.

i don't really think it's a needed function as it won't
support binding of variables and setting the execute mode.
also writing:

$s = ociparse($d, "..."); ociexecute($s);

is "short enough" for most things.

also, cause you "loose" the statement handle you cannot reuse
it. so adding ociquery will make things less optimal.

re,
tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] parse_url still broken!

[Thies C. Arntzen]

url:
file:/bla/test

4.2.x output:
array(2) {
  ["scheme"]=>
  string(4) "file"
  ["path"]=>
  string(9) "/bla/test"
}

HEAD:
array(3) {
  ["scheme"]=>
  string(4) "file"
  ["host"]=>
  string(3) "bla"
  ["path"]=>
  string(5) "/test"
}

re,
tc

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP and OCI8

[Thies C. Arntzen]

On Wed, Oct 23, 2002 at 06:15:19PM +0200, Roderick Groesbeek wrote:
> Howdy People,
> 
> Info:
> ===
> I am witnessing problems with PHP, Apache and OCI8.
> We have profiles on our Oracle databases, so sessions get sniped if they
> hang on to long.

what do you mean by "hang on to long"? you can always fiddle
with your apache config to make sure you don't have too many
inactive oracle-session (when using plogon).

else simply don't use plogon.

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] problem with EG(uninitialized_zval_ptr)

[Thies C. Arntzen]

zee, andi - 

in threded mode we access (atleast)
EG(uninitialized_zval_ptr) before it's initialized ->
BadIdea(tm)

what happens is that (see assert.c as an example)
OnChangeCallback gets called by the ini-mechanism before the
executor is initialized. 

but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks
against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor
anytime before init_executor will cause an UMR.

i know that the startup-order is a very delicate thing so i'd
like to check with you guys first if you have any ideas..

re,
tc


-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)

[Thies C. Arntzen]

On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote:
> TCA>> but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks
> TCA>> against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor
> TCA>> anytime before init_executor will cause an UMR.
> 
> Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...) 
> games than just EG(uninitialized_zval_ptr). So I guess calling 
> zval_ptr_dtor before init_executor is unwise indeed... 

yep - but can we simply move init_executor a bit "up"?

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] problem with EG(uninitialized_zval_ptr)

[Thies C. Arntzen]

On Mon, Oct 28, 2002 at 05:49:44PM -0800, Zeev Suraski wrote:
> At 07:35 28/10/2002, Thies C. Arntzen wrote:
> >On Mon, Oct 28, 2002 at 05:24:38PM +0200, Stanislav Malyshev wrote:
> >> TCA>> but zval_ptr_dtor (used in assert.c-OnChangeCallback) checks
> >> TCA>> against EG(uninitialized_zval_ptr) - so calling zval_ptr_dtor
> >> TCA>> anytime before init_executor will cause an UMR.
> >>
> >> Actually, zval_ptr_dtor calls zval_dtor, which does much more EG(...)
> >> games than just EG(uninitialized_zval_ptr). So I guess calling
> >> zval_ptr_dtor before init_executor is unwise indeed...
> >
> >yep - but can we simply move init_executor a bit "up"?
> 
> Probably not.  Can you simply fix the OnChange callback? :)  NULL up the 
> ASSERTG(callback) on time?

it is(!) nulled in the globals_ctor. the problem is that the
OnChange gets called quite a few times (tested in cli-mode).
and the 2nd call will dtor the "empty" value set by the 1st
call.

also i don't really think that assert.c is the deal here, the
real problem is that we might use parts of the engine "too"
early in many places in the code that i haven't spotted so
far. (and it's a _very_ hard to find thing - i found it using
valgrind)

re,
tc

> 
> Zeev

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] OCISaveLob, OCILoadLob, OCISaveFile?

[Thies C. Arntzen]

On Thu, Oct 31, 2002 at 08:18:12PM +0100, Jean Tardy wrote:
> 
> Hello,
> Who know haw to use those functions:OCISaveLob, OCILoadLob, OCISaveFile?
> Where can I find documentation and sample about this general purpose: 'lob
> object manipulation with oracle"
> Thanks.

http://conf.php.net/slides/oci/paper.txt
> 
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Thies C. Arntzen   -   Looking for all sorts of freelance work  -   just ask..
  http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] OCI patch

[Thies C. Arntzen]

On Thu, Dec 05, 2002 at 11:26:28AM +0100, Abdul-Kareem Abo-Namous
wrote:
> ahem...yes i'd agree on that...i changed it to something more
> meaningful and
> attached a new patch..ah the switching between c and php programming..;)
> 
> the patch is already being used for 2,5 months on an extremly big, extremly
> heavy-load 24x7 platform here at hp europe. basically all european hp sites
> rely on it. so i guess it's being tested :)


cool, so:
 
why not go-ahead and commit it yourself? if you don't already
have a CVS-Acoout it's now time to apply for one;-)

re,
tc
> 
> cheers,
> Abdul
> 
> - Original Message -
> From: "Thies C. Arntzen" <[EMAIL PROTECTED]>
> To: "Abdul-Kareem Abo-Namous" <[EMAIL PROTECTED]>
> Sent: Thursday, December 05, 2002 9:10 AM
> Subject: Re: [PHP-DEV] OCI patch
> 
> 
> > On Mon, Dec 02, 2002 at 02:27:12PM +0100, Abdul-Kareem Abo-Namous wrote:
> > > sure, here's thecode, diff'd against the latest cvs (from today). hope
> it's
> > > ok!
> >
> > sorry for beeing late.
> >
> > the line "if (charset != "\0")" looks bogus to me... you
> > probably meant "if (*charset)" or "if (charset[ 0 ] != '\0')"?
> >
> > besides that it looks OK to me.
> >
> > how well tested is that patch? if it really works for you i
> > think we are save to commit it to HEAD onece the "if" thingie
> > is fixed.
> >
> > re,
> > tc
> >
> > >
> > > oci8_charsets_oci8c.diff is for oci8.c
> > > oci8_charsets_configm4.diff for config.m4 and guess what
> > > oci8_charsets_phpoci8h.diff is for ;-)))
> > >
> > > cheers,
> > > Abdul
> > >
> > > - Original Message -
> > > From: "Maxim Maletsky" <[EMAIL PROTECTED]>
> > > To: "Abdul-Kareem Abo-Namous" <[EMAIL PROTECTED]>
> > > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > Sent: Thursday, November 28, 2002 1:27 PM
> > > Subject: Re: [PHP-DEV] OCI patch
> > >
> > >
> > > >
> > > > Thies was on it. But, I think he is pretty busy right now. Resubmit it
> > > > to me and I will look instead of him. Meanwhile, if Thies has time he
> > > > will spare the light on the issue.
> > > >
> > > > --
> > > > Maxim Maletsky
> > > > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > > "Abdul-Kareem Abo-Namous" <[EMAIL PROTECTED]> wrote... :
> > > >
> > > > > hi everyone
> > > > >
> > > > > what happened to the patch i submitted? is it of such bad quality?
> ;-)
> > > > >
> > > > > maybe someone can tell me more..? :-)
> > > > >
> > > > > thanks,
> > > > > Abdul
> > > > >
> > > > > - Original Message -
> > > > > From: <[EMAIL PROTECTED]>
> > > > > To: "MaximMaletsky" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > > > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > > > Sent: Thursday, October 17, 2002 12:55 PM
> > > > > Subject: Re: Re: [PHP-DEV] OCI patch
> > > > >
> > > > >
> > > > > > Ok, I've attached a pretty ok version. I had to update the
> config.m4
> > > to
> > > > > inculde a HAVE_OCI9 define, but since I'm not really good in this
> kind
> > > of
> > > > > thing, buildconf now reports a warning
> > > > > >
> > > > > > autoheader: No template for symbol `HAVE_OCI9'
> > > > > >
> > > > > > don't know what to do about it. otherwise everything compiles and
> runs
> > > > > smoothly, so I hope you'll enjoy :-).
> > > > > >
> > > > > > Abdul
> > > > > >
> > > > > > Maxim Maletsky <[EMAIL PROTECTED]> schrieb am 17.10.02 12:45:57:
> > > > > > > OK, then.
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Maxim Maletsky
> > > > > > > [EMAIL PROTECTED]
> > > > > > >
> > > > > > >
> > > > > 

Re: [PHP-DEV] php 4.3.0 ext/oci8 -- OCI_SHARED patch

[Thies C. Arntzen]

On Mon, Jan 06, 2003 at 01:42:15PM -0500, Levi Dixon wrote:
> For review:
> 
> I've modified the following files to allow for use of OCI_SHARED in ext/oci8
> module if OCI8_VERSION >= 8.1, which will provide memory savings by sharing
> connection and statement data (refer to
> http://www.csee.umbc.edu/help/oracle8/server.815/a67846/basics.htm; search
> for "Shared Data Mode") between connections and statments respectively.  I
> only have access to ext/oci8, so I can't check this in:
> 
> configure
> main/php_config.h.in
> ext/oci8/config.m4
> ext/oci8/oci8.ca

there should be no nned to change anything outside ext/oci8/
to make this work. configure is auto-generated.

just go ahead and commit the stuff to ext/oci8

> 
> Note: I'm not familiar enough with the windows distribution to add the mod
> there.

neither am i.

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.

[Thies C. Arntzen]

On Mon, Jan 29, 2001 at 06:23:56PM -0600, Brian Moon wrote:
> Ok, so what are the benefits of not returning memory to the system?  It
> seems that no one who can do it wants to so there must be a good reason.Q

in order to be able to "give back" memory to the system we
would have to  switch to an mmap malloc implementation just
for all emalloc'd data - does anyone know such thing that
could be integrated (read: that has an apache-style license)? 

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: PostgreSQL and PHP persistent connections

[Thies C. Arntzen]

On Wed, Feb 07, 2001 at 02:12:26PM -0500, Bruce Momjian wrote:
> Thies, we talked at LinuxWorld about improving the reliability of
> persistent PostgreSQL connections in PHP.

cc'ing php-dev

bruce, 
hope you had a successful show!

> 
> I believe the problem is that persistent connections sometime do not
> pass clean sessions because of open transactions and SET changes to the
> session.

yep...

> 
> We discussed using 'ROLLBACK' before passing a connection to a new user,
> but the problem was that ROLLBACK with no open transaction causes a
> server log error message.  We discussed adding 'ROLLBACK SILENT' to fix
> this, but I believe a better, more portable solution is a simple "BEGIN
> WORK;ROLLBACK".  This will do nothing if there is no open transaction,
> and will ROLLBACK any open transaction.  I propose this be sent by PHP
> as the first query when passing persistent connections.

i'll have a look at that tomorrow (if my family allows;-). if
"BEGIN WORK;ROLLBACK" does not stack transactions i think you
might have found the solution to the php-postgres problem! do
you know how other script-interfaces (perl) to postgres
handle the very same thing?

> 
> As far as SET changes, does anyone on the PostgreSQL interfaces list
> have a suggestion on how to RESET all session parameters?  Seems we may
> need to add this feature in to the backend.

with the oracle driver (i wrote) there is a neat thing in the
oci-libs: you have a server-handle _and_ a session handle.
the session handle sits "on" the server-handle and keeps
_all_ session specific data, the server handle "only" carries
the pure connection to oracle. so i keep the server handle
persistent and allocate/free session handles on it for each
request to PHP. that way the sessions are always clean. but i
also do a forces rollback on the session handle before i free
it on request-end so that in case of a script error all
outstanding transactions are rolled-back.

regards,
tc


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9240: unserialize fails non-determenistic on large objects

[Thies C. Arntzen]

On Tue, Feb 13, 2001 at 03:38:17PM -, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system: RedHat 6.2
> PHP version:  4.0.4pl1
> PHP Bug Type: Variables related
> Bug description:  unserialize fails non-determenistic on large objects
> 
> I'm unserializing a large object using the following test script:
> 
> for ($i = 0; $i < 20; $i++)
> {
>   echo "$i\n";
>   $ObjectToCreate = array();
>   if (!$fp = fopen('test.ser', 'r'))
>   return false;
>   $ObjectToCreate = unserialize(fread ($fp, filesize ('test.ser')));
>   fclose($fp);
> }
> 
> 
> I can supply the 'test.ser' file on request but for obvious reasons do not wish to 
>include it in this error report!

please send it off-list to me. 

thx,
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9276: ORA-00904

[Thies C. Arntzen]

On Thu, Feb 15, 2001 at 12:27:44PM -, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system: linux
> PHP version:  4.0.0
> PHP Bug Type: Oracle related
> Bug description:  ORA-00904

oerr ORA 00904:
invalid column name

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9318: Lots of ORA-24324 warning in apache error_log

[Thies C. Arntzen]

On Sat, Feb 17, 2001 at 02:21:38PM -, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system: RH 6.2 Linux kernel 2.2.16-3
> PHP version:  4.0.3pl1
> PHP Bug Type: OCI8 related
> Bug description:  Lots of ORA-24324 warning in apache error_log
> 
>  There are lots of
> 
> Warning:  failed to rollback outstanding transactions!: ORA-24324: service 
>handle not initialized in /htdocs/admin/lib/error_handler.php on line 
>0
> 
> such error messages in apache error_log file.  Interestingly,  There is no  OCI 
>calls in error_handler.php file. But  this file is included by oci8.php, which has  
>oci connect  and other functions.  oci8.php is  included by other php files (for 
>example product_edit.phtml).
>When I  remove the line including "error_handler.php" in oci8.php , this time 
>same error is occured in oci8.php file.
> 
> Warning:  failed to rollback outstanding transactions!: ORA-24324: service 
>handle not initialized in /htdocs/admin/lib/oci8.php on line 0
> 
> oci8.php file is including oci related custom database functions. Probably this 
>error appears after calling OCIExecute( $stmt, OCI_DEFAULT ).  I need an urgent help. 
> Thanks.

please try to create one short testcase that shows your
problem - 

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] OCI8: searching for testcase that causes "failed to rollback outstanding transactions" or SEGFAULTs

[Thies C. Arntzen]

hi, (sorry for cross-posting)

i'm currently investigating some reported problems with the
PHP 4 OCI8 interface. some people have reported SEGFAULTs and
"failed to rollback outstanding transactions" messages in
their apache error_log. sadly i cannot reproduce any of those
problems on my machine. i would be very happy to hear of
anybody who managed to crash PHP4+OCI8 and who could send me
a _SHORT_ testscript that allows me to reproduce (and fix)
this problem!

regards,
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9197: crash in _efree

[Thies C. Arntzen]

On Mon, Feb 12, 2001 at 09:11:32AM -0700, David Benson wrote:
> > Is there a short script (independent of other scripts) that
> > reproduces this problem?  Can you try to cut it down to the
> > smallest piece of code that still produces a crash?
> 
> Thanks for the response. I've narrowed this down to just a problem (with
> workaround) in Oci8. Included is a short script that reproduces the problem.
> 
> The first part contains a workaround, that I have implemented in my code.
> From the docs I was under the impresison I had to manipulate the clob
> through the clob calls, but OCIFetchStatement appears to handle the data
> correctly.

could you plz try:

load();
?>

if that still causes the crash then the bug is fixed in CVS!

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Time for 4.0.5?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 09:31:01AM +0100, Sascha Schumann wrote:
> Hi,
> 
> what do people think about a PHP 4.0.5 release?
> 
> We have about 70 change entries in NEWS.  Some of the changes
> are fundamentally needed for some extensions to work
> correctly or to compile at all.
> 
> Let me know your thoughts.

anytime - 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] time to upgrade our bundled expat?

[Thies C. Arntzen]

v 1.95.1 is out (http://expat.sourceforge.net)

has anybody played with it?

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] time to upgrade bundled PCRE?

[Thies C. Arntzen]

current version is 3.4 we use 3.2

andrei?

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] time to upgrade our bundled expat?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 02:05:28PM +0100, Emiliano wrote:
> "Thies C. Arntzen" wrote:
> > 
> > v 1.95.1 is out (http://expat.sourceforge.net)
> > 
> > has anybody played with it?
> 
> We use it a lot. Works well, supports multiple charsets, and is now in
> as sane library format so internalizatin isn't strictly necesary
> anymore (although there can be reasons to do so all the same, of
> course).
> 
> Is there anything specific you want to know about it?

-was the upgrade from the original jclark-dist painfull at
 all? 
-are there any known incompatiblities? 
-do you think that if we upgrade the PHP 4 bundled expat
 we'll hit any wall?

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] phpize problem

[Thies C. Arntzen]

sascha,

phpize 
configure

does not work if try to external-compile any bundled modules
as the generated php_config.h is never included (the one from
/usr/local/include is found first) and thereby
the 

#define COMPILE_module_DL 1

is not seen by cpp so that

#ifdef COMPILE_DL_SABLOT
ZEND_GET_MODULE(sablot)
#endif

does not define the get_module() function.

suggestions?
tc




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9197: crash in _efree

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 08:23:42AM -0700, David Benson wrote:
> > could you plz try:
> > 
> >  > $Conn = OCINLogon ('vignette', 'vignette', 'wom_dev');
> > $Clob = OCINewDescriptor($Conn, OCI_D_LOB);
> > $ExtraXML = $Clob->load();
> > ?>
> > 
> > if that still causes the crash then the bug is fixed in CVS!
> 
> Not sure what that was supposed to do ;-), but it caused the same crash.

nothing;-) - but your crash should be fixed in CVS. just examine
your code-snippet again and you'll see that the sequence that
caused your crash can be reduced to the 3 liner i sent.

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] time to upgrade our bundled expat?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote:
> "Thies C. Arntzen" wrote:
> 
> > > We use it a lot. Works well, supports multiple charsets, and is now in
> > > as sane library format so internalizatin isn't strictly necesary
> > > anymore (although there can be reasons to do so all the same, of
> > > course).
> > >
> > > Is there anything specific you want to know about it?
> > 
> > -was the upgrade from the original jclark-dist painfull at
> >  all?
> 
> We haven't seen any API changes ourselves, and I think we use a fairly
> sizeable part of the API. We had our own version of expat-lib, built
> from jclark-dist, and include file name changes aside, it was painless.

cool - i'll try to bump up the bundled expat then.

> 
> > -are there any known incompatiblities?
> 
> Not that I know of, altough ISTR that apache had renamed some function
> names for their internalized version. Our resident expat 'expert' will
> be online in a few hours and I'm sure he can give you more details.

i think we have some namespace protection for "ours" as well.

> 
> > -do you think that if we upgrade the PHP 4 bundled expat
> >  we'll hit any wall?
> 
> In what sense?
> 
> Just to satisfy my curiosity, why is expat being internalized when
> it's available as a library? To minimize external dependancies?

yep, more and more ppl are using xml so bundleing reduces the
"noise" on the ML:-) we did the same with the mysql
client-lib for the very same reason.

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] time to upgrade our bundled expat?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote:
> "Thies C. Arntzen" wrote:
> 
> > > We use it a lot. Works well, supports multiple charsets, and is now in
> > > as sane library format so internalizatin isn't strictly necesary
> > > anymore (although there can be reasons to do so all the same, of
> > > course).
> > >
> > > Is there anything specific you want to know about it?
> > 
> > -was the upgrade from the original jclark-dist painfull at
> >  all?
> 
> We haven't seen any API changes ourselves, and I think we use a fairly
> sizeable part of the API. We had our own version of expat-lib, built
> from jclark-dist, and include file name changes aside, it was painless.
> 
> > -are there any known incompatiblities?
> 
> Not that I know of, altough ISTR that apache had renamed some function
> names for their internalized version. Our resident expat 'expert' will
> be online in a few hours and I'm sure he can give you more details.

maybe they could enlighten me what advantages we'll see if we
upgrade?

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] PHP 4.0 Bug #9876: OCIPLogon flaky after restart Oracle

[Thies C. Arntzen]

On Tue, Mar 20, 2001 at 04:55:31PM -, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system: Redhat 6.1 Linux
> PHP version:  4.0.4pl1
> PHP Bug Type: OCI8 related
> Bug description:  OCIPLogon flaky after restart Oracle
> 
> ./configure' '--prefix=/var/php' '--with-config-file-path=/var/php' 
>'--enable-track-vars'
>   '--enable-sigchild' 
>'--with-apache=../apache_1.3.14' '--with-ftp' '--with-xml'
>   '--with-mcrypt=/var/libmcrypt' 
>'--with-pgsql=/var/postgresql'
>   
>'--with-oci8=/u01/app/oracle/product/8.1.6' '--with-mysql=/var/mysql'
> 
> When using OCIPLogon for persistent connections, I'm noticing that after restarting 
>Oracle, that my PHP application starts getting Oracle errors(ORA-03113 and 
>ORA-03114).  This can be fixed by restarting the webserver after restarting Oracle.  
>I also notice that changing my Oracle connections from OCIPLogon to OCILogon fixes 
>the problem - after making that change I get no errors after restarting Oracle, and I 
>*don't* have to restart the webserver.
> 
> The OCI8 interface must have a bug, right?  I shouldn't have to restart the 
>webserver after restarting Oracle just because I'm using persistent connections, 
>should I?
> 

plz try the latest 4.0.5RC - we have made some changes - and
mayby your problem is solved with it. -but- my expierience is
(and i'm the author of the oci8 interface) that the oci libs
become unstable once you hard-closed some open connections.

you could also comment in some code in do_connect (search for
XXX and oci_ping) which checks if the connection is alive
_before_ returning it to the script.

tc


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Thies C. Arntzen]

On Wed, Mar 21, 2001 at 03:30:58PM +0100, Sascha Schumann wrote:
> 
> Guys, please play by the rules which are laid down in
> RELEASE_PROCESS.  Further decreasing the quality of PHP
> releases doesn't help anyone and just makes us look bad.

i fully agree to sascha. plus i see no real reason to include
a new module once we are in "release-process". new modules
are by default not "producition-stable" so why hurry to
include them in a "official-release"? 

the no. 1 (and maybe only goal) for a release should be
stability and well tested functionality IMHO.

tc


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] non-thread-safe yet pthreads-friendly build of PHP?

[Thies C. Arntzen]

On Tue, Mar 27, 2001 at 09:09:03PM +0200, Zeev Suraski wrote:
> Is there any way to build PHP with pthreads, with ZTS disabled?  The reason 
> I'm asking is that there are some thread-safe 3rd party libraries which are 
> linked against pthreads, and apparently, if PHP isn't built with pthreads - 
> it crashes.  Any experience with it?

i build php agains pthread all the time (cause of oracle) and
it does work for me. you should also link apache agains
-lpthreads as there's aknow glibc issue which could cause
your crash.

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14497 Updated: PHP causes segfault when session handler=user

[Thies C. Arntzen]

On Thu, Dec 20, 2001 at 04:00:15AM -, [EMAIL PROTECTED] wrote:
> ID: 14497
> Updated by: yohgaki
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Analyzed
> Bug Type: Session related
> Operating System: FreeBSD 4.4-Stable
> PHP Version: 4.1.0, 4-200112131200
> New Comment:
> 
> Is this fixed?
> Anyone mind if I fix this and commit?

no - go ahead.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14802: --with-oci8 doesnt grok 64-bit Oracle 9i

[Thies C. Arntzen]

plz replace all OCI8_DIR/lib against OCI8_DIR/lib32 in configure
and try again.

don't forget to report back!

tc

On Wed, Jan 02, 2002 at 03:46:58PM -, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system: Solaris 8
> PHP version:  4.1.1
> PHP Bug Type: Compile Failure
> Bug description:  --with-oci8 doesnt grok 64-bit Oracle 9i
> 
> > less debug.log
> CONFIGURE:   './configure' '--with-fastcgi' '--without-mysql'
> '--with-oci8=/home/oracle/OraHome1' '-
> -enable-mbstr-enc-trans'
> CC: cc
> CFLAGS: -g
> CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS
> CXX:
> CXXFLAGS:
> INCLUDES:  -I/usr/local/include -I$(top_builddir)/Zend
> -I/home/oracle/OraHome1/rdbms/public -I/h
> ome/oracle/OraHome1/rdbms/demo -I/home/oracle/OraHome1/plsql/public
> LDFLAGS: -R/usr/ucblib -L/usr/ucblib -R/home/oracle/OraHome1/lib
> -L/home/oracle/OraHome1/lib
> LIBS:   -ldl -lgen -lsocket -lnsl -lcrypt -lresolv -lresolv -lresolv
> -lm -ldl -lnsl -lsocket  -l
> socket -lcrypt -lclntsh
> DLIBS:
> SAPI:   fastcgi
> PHP_RPATHS:  /usr/ucblib /home/oracle/OraHome1/lib
> uname -a:   SunOS double-eric 5.8 Generic_108528-10 sun4u sparc
> SUNW,Ultra-2
> 
> cc -o conftest -g  -D_POSIX_PTHREAD_SEMANTICS  -R/usr/ucblib -L/usr/ucblib
> -R/home/oracle/OraHome1/l
> ib -L/home/oracle/OraHome1/lib conftest.c -ldl -lgen -lsocket -lnsl -lcrypt
> -lresolv -lresolv -lreso
> lv -lm -ldl -lnsl -lsocket  -lsocket -lcrypt -lclntsh 1>&5
> ld: fatal: file /home/oracle/OraHome1/lib/libclntsh.so: wrong ELF class:
> ELFCLASS64
> ld: fatal: File processing errors. No output written to conftest
> 
> ---
> the 32bit libraries are in  $ORACLE_HOME/lib32
> however, looking at the configure file, I am unable to
> figure out what in the oci8 detection system needs to be
> changed as all the paths are coded as "???/lib"
> 
> 
> -- 
> Edit bug report at: http://bugs.php.net/?id=14802&edit=1
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #14922: OCIBindByName forcing length to 1, even though 0 is a valid length

[Thies C. Arntzen]

On Mon, Jan 07, 2002 at 11:37:16PM -, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system: Solaris
> PHP version:  4.1.0
> PHP Bug Type: OCI8 related
> Bug description:  OCIBindByName forcing length to 1, even though 0 is a valid length
> 
> It seems that the when oci8.c forces value_sz to 1 if it's 0 is bypassing a
> perfectly valid use of a length of 0: To signify a null.  
> 
> See: 
> 
>http://download-west.oracle.com/otndoc/oracle9i/901_doc/appdev.901/a89857/oci03typ.htm

to pass a null thru a bound variable simply assign the
special value NULL to the bound php-variable. the size
supplied to ocibindbyname is simple the max-length of the
inbound variable.

ocibindbyname($stmt,"NAME",$name,32);
$name = NULL;
ociexecute($stmt);

-> ":NAME" will have the value null in the query 

please verify and close the report.

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] free_zval not working?

[Thies C. Arntzen]

On Tue, Jan 22, 2002 at 09:27:53AM +0100, Robin Ericsson wrote:
> I'm using this on php 4.0.6, it know it's old, but things will break if
> I upgrade :)
> 
> This is the code:
> 
>   zval *z_return;
>   MAKE_STD_ZVAL(z_return);
> 
>   php_char_to_str(retval, strlen(retval), '\n', "\n", 5, z_return);
> 
>   FREE_ZVAL(z_return);
> 
> 
> This code gives me:
> string.c(2122) :  Freeing 0x08257CEC (134 bytes), script=nn.php
> 
> which is the new string allocated inside php_char_to_str(), howcome this
> memory isn't freed with FREE_ZVAL?

FREE_ZVAL only frees the zval and does not destroy (read
=free) the attached data-structures. use zval_dtor for that.

tc


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/msession msession.c

[Thies C. Arntzen]

On Tue, Feb 05, 2002 at 09:42:12AM -0500, [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >> Removing backward compatibility for aesthetic reasons is bogus. To be
> >> perfectly honest, I think the whole PHP extension API is truly ugly.
> >> The removal of a few #ifdefs will not a Mona Lisa make.
> > 
> > to me "readability" is a maintainance issue, not an aestheic one ...
> 
> Perhaps for you it is, but not everyone agrees with you. Open source is 
> about freedom, is it not?
> 
> > 
> > if you don't care about others to understand your code, or even don't
> > want anyone to touch it anyway (as you already have made clear), 
> 
> I have made no such declaration. I just do not think well placed #ifdefs 
> affect readability or maintainability. That is your opinion, not mine. I 
> welcome anyone to add features to the msession code as they see fit. All I 
> ask is that they do not remove backward compatibility. This is not an 
> earth shattering request.
> 
> I am really tired of this argument. Why do you care? Why does anyone care? 
> The code is fairly readable, it doesn't do anything hard to understand. It 
> is a simple thunk/trasport layer for another library all together. If 
> anyone has trouble reading or understanding it, I would suggest that they 
> need to take a basic C class.
> 
> More over, I think msession, while still a bit experimental, is a 
> worthwhile addition to PHP. I already have a few people using it and it 
> has helped them deploy their web farm. People are using it, and in doing 
> so people are using PHP for big things. As I understand it, this is what 
> we all want, right?
> 
> I think very highly of PHP. It is a great project. I submited my extension 
> to add value to the project. I think it can add value and help moderately 
> large installations.
> 
> All I am asking is that, as one developer, that backward compatibiliy 
> remains so I do not have to maintain two branches and duplicate work. My 
> time is valuable, why should I waste it? This is not a lot to ask and I 
> simply do not understand what the problem is. In any professional 
> environment, this would be a no-brainer. You do not remove backward 
> compatibility if you do not need to do so.

the problem as i see it is that everything in the php4/ CVS
is worked on by several ppls. we invent a new API and
somebody goes and implements that in some modules (and mybe
not in some other). 

the new parameter-parsing API was introduced by andrei some
month ago and we decided to switch to this api. even thogh i
haven't been very active lately i did a big chink of work
porting modules from php3 to php4 and -no- i did not ask the
official maintainer if they want to port it. there was an
itch and i scrachted it. having a new/better API certainly is
an itch and having both the old and the new one in one file
is something we've never done in the past.

i agree with hartmut that we don't care for backward
compatiblity in modules that are in the php4/ cvs. so if you
need to have support for anything but php4-HEAD in your
module it probably doesn't belong to php4-HEAD.

PECL on the other hand is a completely different story, and
if i was you i would "move places".

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Bug #15390: Persistent OCI8 Connections Get Poisoned

[Thies C. Arntzen]

On Tue, Feb 05, 2002 at 09:10:57PM -0500, George Schlossnagle wrote:
> Isn't there handling for this in current cvs code?  I remember 
> submitting a patch for this (and assoicated problems) to Thies, and it 
> being accepted. 

there is - but there seem to be some error-codes missing.
george, you run a big PHP-oracle site if i recall right - ist
it working to your satisfaction?

tc
> 
> George 
> 
> On Tuesday, February 5, 2002, at 04:23 PM, Hans Zaunere wrote: 
> 
> 
> >   
> > Good idea (for the situation anyway).  It works.  I have all custom 
> > error handlers anyway, so when I detect a ORA-03313 error, I kill 
> > the current process with a SIGTERM.  Since I use header() to 
> > redirect to the error page, sometimes I get a blank page, but 
> > atleast when the database comes back, the whole system is back. 
> > Although PHP should handle this better in some manner.  :) 
> > 
> > Thank you, 
> > 
> > Hans 
> > 
> > [EMAIL PROTECTED] wrote: 
> > 
> > We are seeing this problem too. I am thinking of having a standard 
> > error 
> > page which executes 
> > 
> > posix_kill ( pos_getpid()) ; 
> > 
> > On Oracle errors. 
> > 
> > > From: [EMAIL PROTECTED] 
> > > Operating system: RedHat 6.2 
> > > PHP version:  4.0.6 
> > > PHP Bug Type: OCI8 related 
> > > Bug description:  Persistent OCI8 Connections Get Poisoned 
> > > 
> > > I have PHP 4.0.6 compiled as an Apache 1.3.20 module with OCI8 
> > and 
> > > MySQL on RedHat 6.2.  I use persistent connections with OCI8 to 
> > avoid 
> > > the costly connection construction for Oracle for each request. 
> > > However, I notice that these persistent connections get 
> > "poisoned" 
> > > under certain 
> > > circumstances.  What I mean by this is this: 
> > > 
> > > Since each persistent connection stays with it's corresponding 
> > Apache 
> > > process, if the database happens to be down when a request comes 
> > in, 
> > > the persistent connection that is used throws an ORA-03113.  
> > However, 
> > > even when the database comes back, the persistent connection 
> > still 
> > > thinks the database is down somehow, and will continue to throw 
> > the 
> > > ORA-03113 error.  As a result, if a request happens to hit the 
> > poisoned 
> > > Apache process, it appears the database is down.  If a request 
> > hits 
> > > another Apache process, all is OK. 
> > > 
> > > So far, the only way I've seen to deal this is to restart Apache, 
> > and 
> > > have the persistent connections build up again.  Obviously, this 
> > is not 
> > > a good thing, and if database connectivity is lost in any form, 
> > the 
> > > persistent connections get poisoned again, and the cycle begins. 
> > > 
> > > Now as this might not be a bug per se, I would think that 
> > persistent 
> > > connections should at least check that they aren't corrupted in 
> > some 
> > > way; or 'freshen' themselves.  Although I haven't tested it 
> > fully, I 
> > > have never seen this behavior with persistent MySQL connections. 
> > > 
> > > Please contact me for any further details or clarification if 
> > needed. 
> > > 
> > > Thank you, 
> > > 
> > > Hans 
> > > -- 
> > > Edit bug report at http://bugs.php.net/?id=15390&edit=1 
> > > -- 
> > > Fixed in CVS:    
> > http://bugs.php.net/fix.php?id=15390&r=fixedcvs 
> > > Fixed in release: 
> > > http://bugs.php.net/fix.php?id=15390&r=alreadyfixed Need 
> > backtrace: 
> > >  http://bugs.php.net/fix.php?id=15390&r=needtrace Try newer 
> > version: 
> > > http://bugs.php.net/fix.php?id=15390&r=oldversion Not developer 
> > issue: 
> > > http://bugs.php.net/fix.php?id=15390&r=support Expected behavior: 
> > > http://bugs.php.net/fix.php?id=15390&r=notwrong Not enough info: 
> > > http://bugs.php.net/fix.php?id=15390&r=notenoughinfo 
> > > 
> > > 
> > > -- 
> > > PHP Development Mailing List  
> > > To unsubscribe, visit: http://www.php.net/unsub.php 
> > 
> > 
> > 
> // George Schlossnagle 
> // 1024D/1100A5A0  1370 F70A 9365 96C9 2F5E 56C2 B2B9 262F 1100 A5A0 
> 
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]

[Thies C. Arntzen]

On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote:
> Hi all,
> 
> I'm posting this for those who are not subscribing
> Zend Engine 2 list.
> 
> Many of developers seems to have case sensitivity for
> class/function names.
> However, we need vote for if PHP5 will have case
> sensitive class/function/constant names.
> 
> If you have comments, please submit one.
> 
> PS: We know we can cheat. Let's hope nobody cheat :)
> You can read Zend Engne 2 list archive at
> http://www.zend.com/lists.php

besides the BC mess i'm all for it (make PHP5 case-sensite).

tc

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)

[Thies C. Arntzen]

On Sat, Feb 09, 2002 at 01:41:21AM +0200, Zeev Suraski wrote:
> I think that's a nightmare, WTF-factor wise...  Just my 0.02NIS

how much is that in euro?

> 
> Zeev
> 
> At 12:14 AM 2/9/2002, Jason Greene wrote:
> >If you are already thinking about storing the case sensitive name for
> >the class/function why not follow Rasmus's suggestion for calling the
> >exact case function first, then look for a case insens match.
> >
> >search case preserved function_table
> >if not found {
> >search lowercase function_table
> >if not found die with "Unknown function"
> >}
> >
> >There is no performance penalty unless you mix case. There is of course
> >the extra memory needed for 2 tables.
> >
> >>
> >--
> >Jason T. Greene
> >Internet Software Engineer
> >
> ><[EMAIL PROTECTED]>
> ><[EMAIL PROTECTED]>
> ><[EMAIL PROTECTED]>
> >
> >Use PHP: http://www.php.net
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [patch] one script to handle them all

[Thies C. Arntzen]

On Wed, Feb 13, 2002 at 12:36:49PM +0100, Lukas Schroeder wrote:
> On Wed, Feb 13, 2002 at 08:13:42AM +0100, Markus Fischer wrote:
> > Patches should always be against latest CVS.
> 
> here it is. against latest CVS.

how does this compare the the work rasmnus has done some time
ago - see attached mail?

re,
tc
> 
> 
> 
> regards,
>   -lukas
>  

> Index: sapi/apache/mod_php4.c
> ===
> RCS file: /repository/php4/sapi/apache/mod_php4.c,v
> retrieving revision 1.127
> diff -u -r1.127 mod_php4.c
> --- sapi/apache/mod_php4.c11 Dec 2001 15:31:53 -  1.127
> +++ sapi/apache/mod_php4.c13 Feb 2002 11:20:58 -
> @@ -483,6 +483,39 @@
>  }
>  /* }}} */
>  
> +/* {{{ php_get_request_handler
> + */
> +static int php_get_request_handler(request_rec *r, char **target)
> +{
> + HashTable *per_dir_conf;
> + php_per_dir_entry *per_dir_entry;
> + char *filename;
> +
> + if (!(per_dir_conf = get_module_config(r->per_dir_config, &php4_module)))
> + return 0;
> +
> + if (zend_hash_find(per_dir_conf, "request_handler", 
>sizeof("request_handler")-1,
> + (void **)&per_dir_entry) == SUCCESS) {
> +
> + if (!ap_os_is_path_absolute(per_dir_entry->value)) {
> + char *dirnam = ap_pstrdup(r->pool, r->filename);
> + char *x = strrchr(dirnam, '/');
> +
> + if (x != NULL)
> + *x = 0;
> + filename = ap_make_full_path(r->pool, dirnam, 
>per_dir_entry->value);
> + }
> + else
> + filename = ap_pstrdup(r->pool, per_dir_entry->value);
> +
> + *target = filename;
> + return 1;
> + }
> +
> + return 0;
> +}
> +/* }}} */
> +
>  /* {{{ send_php
>   */
>  static int send_php(request_rec *r, int display_source_mode, char *filename)
> @@ -502,6 +535,9 @@
>   return OK;
>   }
>  
> + if (php_get_request_handler(r, &filename))
> + r->filename = filename;
> +
>   zend_first_try {
>   /* We don't accept OPTIONS requests, but take everything else */
>   if (r->method_number == M_OPTIONS) {
> @@ -846,6 +882,26 @@
>  }
>  /* }}} */
>  
> +/* {{{ php_type_checker
> + */
> +static int php_type_checker(request_rec *r)
> +{
> + char *filename;
> + 
> + /* if a request_handler has been registered, the type checker tells 
> +  * apache to invoke our send_php handler; otherwise we deny responsibility
> +  * for this request
> +  */
> + 
> + if (php_get_request_handler(r, &filename)) {
> + r->handler = "application/x-httpd-php";
> + return OK;
> + }
> + 
> + return DECLINED;
> +}
> +/* }}} */
> +
>  /* {{{ handler_rec php_handlers[]
>   */
>  handler_rec php_handlers[] =
> @@ -885,7 +941,7 @@
>   NULL,   /* check_user_id */
>   NULL,   /* check auth */
>   NULL,   /* check access */
> - NULL,   /* type_checker */
> + php_type_checker,   /* type_checker */
>   NULL,   /* fixups */
>   NULL/* logger */
>  #if MODULE_MAGIC_NUMBER >= 19970103
> 

> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php

--- Begin Message ---

rasmus  Thu Sep  6 05:53:34 2001 EDT

  Modified files:  (Branch: apache_hooks)
/php4/main  main.c php_main.h 
/php4/sapi/apache   mod_php4.c mod_php4.h php_apache.c 
  Log:
  Apache request handler hook framework.  So far only the uri hook is
  implemented, but the others will be easy once I finish the uri translation
  example.  The big things left to do is to create a proper $r request
  object to be manipulated in user-space and also to verify that the hooks
  don't steal the POST data such that it isn't available to the content
  handler once it is finally called.  Or if we do steal it, make sure it
  is somehow available to the content handler later on.
  
  Comments and help with this stuff is more than welcome.  Check out these
  files from the 'apache_hooks' branch to play along.  
  
  

Index: php4/main/main.c
diff -u php4/main/main.c:1.407 php4/main/main.c:1.407.2.1
--- php4/main/main.c:1.407  Fri Aug 31 10:34:40 2001
+++ php4/main/main.cThu Sep  6 05:53:33 2001
@@ -18,7 +18,7 @@
+--+
 */
 
-/* $Id: main.c,v 1.407 2001/08/31 14:34:40 zeev Exp $ */
+/* $Id: main.c,v 1.407.2.1 2001/09/06 09:53:33 rasmus Exp $ */
 
 /* {{{ includes
  */
@@ -692,6 +692,35 @@
 }
 /* }}} */
 
+/* {{{ php_request_startup_for_hook
+ */
+int php_r

Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?

[Thies C. Arntzen]

On Thu, May 17, 2001 at 11:10:57PM -0700, Rasmus Lerdorf wrote:
> > >>Perhaps automatic detection could be option?  if (filesize > X)
> > >>blockread else mmap?  It seems like the most intuitive way to implement
> > >>it...
> > >>
> > >
> > > Sounds a bit magical.  Why not just a block_readfile() function?
> >
> >
> > Mainly the bloat factor, we already have a large core, imho, functions
> > shouldn't be added unless there are no workarounds.  Also, it requires a
> > little too much thought, into what sizes are good for mmap() and what
> > sizes are good for block read's (it also requires knowledge of mmap(),
> > because many people might automatically assume that block_read would
> > always be faster).  I'm pretty sure if we polled php-general and php-qa
> > (the more "knowledgable" user bases), most people wouldn't really
> > understand what mmap does, or what it is for or when it is beneficial to
> > use it.
> >
> > As for magical, well a bit, but good magic and internal magic (not
> > syntactical magic).  I'd assume that most systems have a certain point
> > where mmap is no longer more beneficial than reading a file by chunks.
> > If we can find a reasonable number (or have a user specify that in a
> > configuration option if really necessary), it saves the user the trouble
> > of thinking about something which is pretty low-level and it reduces
> > bloat.  I don't really see a downside to this magic.
> 
> But, the issue here isn't one of which is faster.  The issue here is one
> of memory usage.  If you have a 600M iso image that you decide to
> readfile() for a download page of some sort, then you are going to end up
> with a 600M httpd process.  And soon you will have lots of those as more
> people hit the page.

mmap will not increase the size of your process as it doesn't
call sbrk(). 

> 
> So to be truely magical here, PHP would have to check the amount of spare
> RAM on the system, divide that by MaxClients and set that as the largest
> filesize to mmap() because anything larger could result in the box going
> into swap.
> 
> I obviously don't think such a check is feasible.  The only real question
> here is whether to add a user configurable max-mmap setting or to add a
> second function that never mmaps.

question is: do we really need this mmap stuff at all?

with readfile we should easyly be able to saturate a
pipe of any size using just read and write.

tc

> 
> -Rasmus
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] proposed change in the build-system.

[Thies C. Arntzen]

hi sascha,
i would love if we could reduce the output of make from

..
/bin/sh /home/thies/devel/apxs/libtool --silent --silent
--mode=link gcc  -I. -I/home/thies/devel/php4/main
-I/home/thies/devel/apxs/main -I/home/thies/devel/php4
-I/usr/include/apache -I/home/thies/devel/apxs/Zend
-I/usr/include/freetype2/freetype -I/usr/include/imap
-I/home/thies/devel/php4/ext/mysql/libmysql
-I/home/oracle/805/rdbms/demo -I/home/oracle/805/network/public
-I/home/oracle/805/plsql/public
-I/home/thies/devel/php4/ext/xml/expat
-I/home/thies/devel/apxs/TSRM -I/home/thies/devel/php4/main
-I/home/thies/devel/php4/Zend -I/home/thies/devel/php4/TSRM
-DLINUX=22 -DDEV_RANDOM=/dev/random -DEAPI -DEAPI_MM -DUSE_EXPAT
-g -O2 -prefer-pic   -o libmain.la  main.lo internal_functions.lo
snprintf.lo php_sprintf.lo safe_mode.lo fopen_wrappers.lo
alloca.lo php_ini.lo SAPI.lo rfc1867.lo php_content_types.lo
strlcpy.lo strlcat.lo mergesort.lo reentrancy.lo php_variables.lo
php_ticks.lo streams.lo network.lo php_open_temporary_file.lo
php_logos.lo
...

to something like:

Using CFLAGS=-I/home/thies/devel/php4/main
-I/home/thies/devel/apxs/main -I/home/thies/devel/php4
-I/usr/include/apache -I/home/thies/devel/apxs/Zend
-I/usr/include/freetype2/freetype -I/usr/include/imap
-I/home/thies/devel/php4/ext/mysql/libmysql
-I/home/oracle/805/rdbms/demo -I/home/oracle/805/network/public
-I/home/oracle/805/plsql/public
-I/home/thies/devel/php4/ext/xml/expat
-I/home/thies/devel/apxs/TSRM -I/home/thies/devel/php4/main
-I/home/thies/devel/php4/Zend -I/home/thies/devel/php4/TSRM
-DLINUX=22 -DDEV_RANDOM=/dev/random -DEAPI -DEAPI_MM -DUSE_EXPAT
-g -O2 -prefer-pic
Compiling /home/thies/devel/php4/ext/standard/array.c
Compiling /home/thies/devel/php4/ext/standard/file.c
Linking libstandart.la

that's how a samba compile looks like. this would make the
output of the "make" way more shorter & readable.

what do you think?
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: proposed change in the build-system.

[Thies C. Arntzen]

On Wed, Jun 20, 2001 at 12:36:35PM +0200, Sascha Schumann wrote:
> > that's how a samba compile looks like. this would make the
> > output of the "make" way more shorter & readable.
> 
> This makes sense when the various parameters are constant
> throughout the whole build (which seems to be the case in
> Samba).  How do you propose to handle additions to e.g.
> CFLAGS in extension subdirectories?

maybe have another 'Using CFLAGS="-I.."' line in the output -or-
just say 'Adding to CFLAGS="blabla"' when it happens. 

haven't really thought about that;-) - we could even have one
'Using CFLAGS=""' whenever we enter a directory?

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11432 Updated: crash when restoring references to objects

[Thies C. Arntzen]

please try attached patch and report back!

tc

On Tue, Jun 12, 2001 at 05:40:40PM -, [EMAIL PROTECTED] wrote:
> ID: 11432
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Status: Open
> Bug Type: Reproducible crash
> Operating system: 
> PHP Version: 4.0.5
> Assigned To: 
> Comments:
> 
> reproduced with 4.0.6RC3
> 
> 
> Previous Comments:
> ---
> 
> [2001-06-12 08:29:39] [EMAIL PROTECTED]
> Here are two scripts that operates on referenced objects. make.php creates object $b 
>with reference to object $a as argument.
> 
> After serialize/unserialize show.php checks if the reference still exists.
> 
> PHP 4.0.1pl1 lost references.
> PHP 4.0.4pl1 segfaults on show.php
> PHP 4.0.5segfaults on show.php and(!) sometimes on make.php
> 
> Config line:
> ./configure --with-pgsql=shared --with-apxs --sysconfdir=/etc --prefix=/usr 
> --localstatedir =/var --with-config-file-path=/etc/httpd/conf/ 
> --with-gettext=/usr/share/gettext
> 
> make.php:
>  class ClassA {
>  var $arg_a;
> };
> 
> class ClassB {
>   var $arg_b;
>  
>   function ClassB(&$a) {
>   $this -> arg_b = &$a;
>   }
> };
> 
> session_start();
> session_destroy();
> session_register("b");
> session_register("a");
> 
> $a = new ClassA();
> $a -> arg_a = 4;
> $b = new ClassB($a);
> echo "done. Click here";
> ?>
> 
> 
> show.php:
>  class ClassA {
>  var $arg_a;
> };
> 
> class ClassB {
>   var $arg_b;
>  
>   function ClassB(&$a) {
>   $this -> arg_b = &$a;
>   }
> };
> 
> session_start();
> $a -> arg_a = 6;
> echo $b -> arg_b -> arg_a;
> ?>
> 
> ---
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=11432&edit=2
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


? .session.c.swp
Index: session.c
===
RCS file: /repository/php4/ext/session/session.c,v
retrieving revision 1.210
diff -u -r1.210 session.c
--- session.c   10 Jun 2001 23:26:35 -  1.210
+++ session.c   20 Jun 2001 14:47:46 -
@@ -405,7 +405,6 @@
 
PHP_VAR_UNSERIALIZE_INIT(var_hash);
 
-   MAKE_STD_ZVAL(current);
for (p = q = val; (p < endptr) && (q = memchr(p, PS_DELIMITER, endptr - p)); p 
= q) {
if (p[0] == PS_UNDEF_MARKER) {
p++;
@@ -418,16 +417,18 @@
name = estrndup(p, namelen);
q++;

+   MAKE_STD_ZVAL(current);
if (has_value) {
if (php_var_unserialize(¤t, &q, endptr, &var_hash)) {
+   
php_set_session_var(name, namelen, current PSLS_CC);
-   zval_dtor(current);
}
}
PS_ADD_VARL(name, namelen);
efree(name);
+   zval_ptr_dtor(¤t);
+   //FREE_ZVAL(current);
}
-   FREE_ZVAL(current);
 
PHP_VAR_UNSERIALIZE_DESTROY(var_hash);
return SUCCESS;



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11432 Updated: crash when restoring references to objects

[Thies C. Arntzen]

On Wed, Jun 20, 2001 at 04:47:43PM +0200, Thies C. Arntzen wrote:
> please try attached patch and report back!

this patch fixes the crash - the reference is still fu**ed
afetr the 2nd reload - switching my brain into 2nd gear;-)

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11432 Updated: crash when restoring references to objects

[Thies C. Arntzen]

On Wed, Jun 20, 2001 at 06:47:46PM +0200, Jani Taskinen wrote:
> On Wed, 20 Jun 2001, Thies C. Arntzen wrote:
> 
> >On Wed, Jun 20, 2001 at 04:47:43PM +0200, Thies C. Arntzen wrote:
> >> please try attached patch and report back!
> >
> >this patch fixes the crash - the reference is still fu**ed
> >afetr the 2nd reload - switching my brain into 2nd gear;-)
> 
> You committed something to latest CVS? I guess it was the really
> working patch then? :)

yup it is.

> 
> Are you going to MFH it ?? I think this should go into 4.0.6.
> It has been broken so long now.

no too sure as it really changes a few internals and needs
_good_ testing!

comments?

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11432 Updated: crash when restoring references to objects

[Thies C. Arntzen]

On Wed, Jun 20, 2001 at 07:05:23PM +0200, Jani Taskinen wrote:
> On Wed, 20 Jun 2001, Thies C. Arntzen wrote:
> 
> >> Are you going to MFH it ?? I think this should go into 4.0.6.
> >> It has been broken so long now.
> >
> >no too sure as it really changes a few internals and needs
> >_good_ testing!
> >
> >comments?
> 
> Nope. I can't test it. The HEAD branch doesn't work for me at all
> Not since the upgrade to libtool 1.4. That's why I asked if you're
> gonna MFH. :)

hmm - there are some more changes in the session module
between PHP_4_0_6 and HEAD. i will not merge my changes into
4.0.6 - your choices: a) use HEAD b) merge HEAD version of
session into your current PHP c) wait for 4.0.7

sorry,
tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] "make test" doesn't work with register_globals=Off

[Thies C. Arntzen]

is this acceptable?

comments?
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] can we cange the "important" defines to enums in the zend-headers, please?

[Thies C. Arntzen]

hi,

it would make debugging for guys like me easier, as gdb will
then be able to show IS_OBJECT instead of 5 when
inspecting zvals. (gdb nows about the sybolic name for an
enum but not for a define).

if you don't object i'll go ahead soon

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #11749 Updated: Unserialize dies with Apache Module but is FINE with CGI

[Thies C. Arntzen]

On Wed, Jun 27, 2001 at 06:32:13PM -, [EMAIL PROTECTED] wrote:
> ID: 11749
> User Update by: [EMAIL PROTECTED]
> Status: Open
> Bug Type: Scripting Engine problem
> Operating system: Win32 (Win 2k)
> PHP Version: 4.0.6
> Description: Unserialize dies with Apache Module but is FINE with CGI
> 
> If it helps:
> 
> a)Script
> b)Datafile

works on linux.
please try changing 

@fopen($FileLocation,"r");
to 
@fopen($FileLocation,"rb");

and
fopen($FileLocation,"w");
to
fopen($FileLocation,"wb");


to force binary mode for your file - i'm pretty sure it will
fix your problem!

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] 2 problems with shutdown

[Thies C. Arntzen]

hi,

we have two problems in the current code when it comes to
shutting down apache processes:

1)
in main.c php_module_shutdown():
we call php_config_ini_shutdown() before we call the modules
MSHUTDOWN functions - which basically means that php is
already "half-dead" when MSHUTDOWN is called - so modules can
can not rely on certain things (like error_log settings)
during MSHUDOWN. is there any known reason not to move
php_config_ini_shutdown() further down in
php_module_shutdown()?


2) (more serious)
if you do an "apachectl restart" the master httpd will signal
the worker httpd's. the workers will than call the
child_exit hook in all modules no matter where in the code
they just happen to be. the problem is that we "try"
to clean up the best we can -but- this might cause recursive
calls into 3th party library code (which is not supported in
most cases!)

sample:

script calls ociexecute($stmt) (which might take a few
seconds)  now the  admin does "apachectl restart" - and we
get interrupted deep down in the oci library. now the worker
httpd tries to clean up and calls the child_exit hooks.  php
will now free all resources and it will also try to do a
rollback on $stmt and after that it'll free $stmt. the
problem here is that the oracle-server _doesn't_ like
recursive calls at all and might crash just 'cause of that.

OK - i agree - oracle should fix their code, -but- i don't
think its smart to try a real-cleanup if we we're
interrunpted during a request. i think we need to protect the
engine agains recursive calls. so if child_exit is called
while we're still in execution mode simply do nothing
(bacause all we could do might be harmful) and leave the
clean up to unix.

comments?
tc


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] keeping descriptors in persistent connections

[Thies C. Arntzen]

On Thu, Jun 28, 2001 at 11:18:11AM +0200, [EMAIL PROTECTED] wrote:
> Hello Joao,
> 
> On Wed, 27 Jun 2001, Joao Conceicao wrote:
> 
> > Hi,
> > I'm having a problem making a module that uses persistent connections.
> > It's possible to reuse the same descriptors (file descriptors) in two
> > diferent pages? How?

see
http://marc.theaimsgroup.com/?l=php-general&m=96142518330489&w=2
for some __sleep __wakeupp sample code.
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: 2 problems with shutdown

[Thies C. Arntzen]

ping?

On Thu, Jun 28, 2001 at 05:45:13PM +0200, Thies C. Arntzen wrote:
> 
> hi,
> 
> we have two problems in the current code when it comes to
> shutting down apache processes:
> 
> 1)
> in main.c php_module_shutdown():
> we call php_config_ini_shutdown() before we call the modules
> MSHUTDOWN functions - which basically means that php is
> already "half-dead" when MSHUTDOWN is called - so modules can
> can not rely on certain things (like error_log settings)
> during MSHUDOWN. is there any known reason not to move
> php_config_ini_shutdown() further down in
> php_module_shutdown()?
> 
> 
> 2) (more serious)
> if you do an "apachectl restart" the master httpd will signal
> the worker httpd's. the workers will than call the
> child_exit hook in all modules no matter where in the code
> they just happen to be. the problem is that we "try"
> to clean up the best we can -but- this might cause recursive
> calls into 3th party library code (which is not supported in
> most cases!)
> 
> sample:
> 
> script calls ociexecute($stmt) (which might take a few
> seconds)  now the  admin does "apachectl restart" - and we
> get interrupted deep down in the oci library. now the worker
> httpd tries to clean up and calls the child_exit hooks.  php
> will now free all resources and it will also try to do a
> rollback on $stmt and after that it'll free $stmt. the
> problem here is that the oracle-server _doesn't_ like
> recursive calls at all and might crash just 'cause of that.
> 
> OK - i agree - oracle should fix their code, -but- i don't
> think its smart to try a real-cleanup if we we're
> interrunpted during a request. i think we need to protect the
> engine agains recursive calls. so if child_exit is called
> while we're still in execution mode simply do nothing
> (bacause all we could do might be harmful) and leave the
> clean up to unix.
> 
> comments?
> tc
> 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: 2 problems with shutdown

[Thies C. Arntzen]

On Fri, Jun 29, 2001 at 03:23:03PM +0300, Zeev Suraski wrote:
> At 15:18 29/6/2001, Thies C. Arntzen wrote:
> >agreed - but we should do it, right?
> 
> Yup :)
> 
> >in the error_log - and sometimes it'll even SEGFAULT.
> >
> >is this good?
> 
> Is this a trick question?  :)  Of course it's bad.  Perhaps we should 
> revert to only freeing registered resources on a child_exit 
> (module_shutdown, I guess).  We can live without actually freeing malloc'd 
> memory, as indeed, it will be auto-freed upon exit anyway.

sorry for bashing this;-) i'm sure i'll be able to crash it
using any 3th party module. because the restart signal can
"hit" us any time. 

does anybody know how other apache-modules handle this
situation? 

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: 2 problems with shutdown

[Thies C. Arntzen]

On Fri, Jun 29, 2001 at 02:09:44PM +0300, Zeev Suraski wrote:
> At 18:45 28/6/2001, Thies C. Arntzen wrote:
> 
> >hi,
> >
> >we have two problems in the current code when it comes to
> >shutting down apache processes:
> >
> >1)
> >in main.c php_module_shutdown():
> >we call php_config_ini_shutdown() before we call the modules
> >MSHUTDOWN functions - which basically means that php is
> >already "half-dead" when MSHUTDOWN is called - so modules can
> >can not rely on certain things (like error_log settings)
> >during MSHUDOWN. is there any known reason not to move
> >php_config_ini_shutdown() further down in
> >php_module_shutdown()?
> 
> The problem is that (if I remember correctly) the INI mechanism may call 
> callbacks in modules that have already been unloaded.  It can probably be 
> fixed, but would require some time to play with.

agreed - but we should do it, right?

> 
> 
> >2) (more serious)
> >if you do an "apachectl restart" the master httpd will signal
> >the worker httpd's. the workers will than call the
> >child_exit hook in all modules no matter where in the code
> >they just happen to be. the problem is that we "try"
> >to clean up the best we can -but- this might cause recursive
> >calls into 3th party library code (which is not supported in
> >most cases!)
> >
> >sample:
> >
> >script calls ociexecute($stmt) (which might take a few
> >seconds)  now the  admin does "apachectl restart" - and we
> >get interrupted deep down in the oci library. now the worker
> >httpd tries to clean up and calls the child_exit hooks.  php
> >will now free all resources and it will also try to do a
> >rollback on $stmt and after that it'll free $stmt. the
> >problem here is that the oracle-server _doesn't_ like
> >recursive calls at all and might crash just 'cause of that.
> >
> >OK - i agree - oracle should fix their code, -but- i don't
> >think its smart to try a real-cleanup if we we're
> >interrunpted during a request. i think we need to protect the
> >engine agains recursive calls. so if child_exit is called
> >while we're still in execution mode simply do nothing
> >(bacause all we could do might be harmful) and leave the
> >clean up to unix.
> 
> I don't know if that qualifies as a recursive call - it's really doing what 
> it's supposed to do.  Perhaps the Oracle module should protect itself, but 
> not running cleanup is wrong IMHO - consider semaphores or the likes which 
> won't clean up automatically.  Or SQL servers that won't immediately detect 
> that their client is gone.  I think that cleaning up is generally an 
> important thing.

i agree - in theory. but "apachectl restart" will sometimes
SEGFAULT some httpd processes because of php. just create a
trivial page that will take some time:

test.php


run "ab -n1000 http://0/test.php";

and then do an apachectl restart (a few times) and you'll see

zend_execute.c(376) :  Freeing 0x08162BDC (12 bytes), script=/var/www/html/t.php
zend_hash.c(287) :  Freeing 0x08162B84 (37 bytes), script=/var/www/html/t.php Last 
leak repeated 160 times
zend_opcode.c(303) :  Freeing 0x08161AEC (720 bytes), script=/var/www/html/t.php
zend_language_scanner.c(4153) :  Freeing 0x08162B4C (2 bytes), 
script=/var/www/html/t.php
zend_opcode.c(237) :  Freeing 0x08162B0C (12 bytes), script=/var/www/html/t.php
zend_language_scanner.c(4238) :  Freeing 0x08162AD4 (2 bytes), 
script=/var/www/html/t.php Last leak repeated 2 times
zend_opcode.c(71) :  Freeing 0x08161AB4 (4 bytes), script=/var/www/html/t.php
zend_compile.c(118) :  Freeing 0x081619C4 (20 bytes),
...

in the error_log - and sometimes it'll even SEGFAULT.

is this good?

tc


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Assert callback handlers

[Thies C. Arntzen]

On Thu, Jun 28, 2001 at 05:42:35PM -0400, Jon Parise wrote:
> On Thu, Jun 28, 2001 at 05:23:41AM -0600, Zak Greant wrote:
> 
> > Can anyone see any problems with adding array (&$object, 'method') syntax to
> > the assert handler functionality?
>  
> I think that would be fiarly useful, actually.  In the past, I've
> just written whole functions that sort of mimic assert(), but
> this would be much better.

will implement this shortly!
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] RE: Bug #11749 Updated: Unserialize dies with Apache Module but is FINE with CGI

[Thies C. Arntzen]

On Fri, Jun 29, 2001 at 03:31:25AM -0700, Brian Tanner wrote:
> You may consider it fixed if you like.
> 
> However... the data file failed to load in Module, and did load in CGI.
> 
> Shouldn't they be identical?

yes they should. but there should be _no_ difference in the
fopen() PHP function between the module and the cgi. if there
is a difference than the environment bewteen the two must be
different!

there's not a lot we can do from here -plus- it's obvious
that you _must_ use binary mode for files that contain
serialized data with CR in them!

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [Zend Engine 2] substr changes

[Thies C. Arntzen]

On Tue, Jul 03, 2001 at 03:07:37AM +0200, Andre Langhorst wrote:
> >Just one thing I did want to point out - this has nothing to do with 
> >Zend 3 or whatever.  I oppose this feature not because lack of time to 
> >implement it or because it's difficult to implement, but because it 
> >doesn't belong in PHP.  Personally, I wouldn't want to see it even in 
> >PHP 7.0...
> 
> 
> although disagreeing, I agree in completely skipping this then, as 
> previously proposed...
> 
> what about operator overloading in exchange? ;)

i think that's even worse.

i can happily life without it!
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] new/different problem in shutdown

[Thies C. Arntzen]

zeev,andi

i have a problem with the oci-extension - it makes heaviy
usage of ref-counting and creates dependices between resouces
using refcounts. so i depend on a defined shutdown order and
i also depend on the complete symbol-table to be destroyed
before zend_destroy_rsrc_list is called as zend_destroy_rsrc_list 
won't work with my dependicies. 

i have created a small testcase that shows my problem without
using the oci extension: 

the problem is that if a function calles exit the argumets
for that function are _not_ destroyed in the shutdown
mechanism of zend -




if i set a breakpoint in _file_fopen_dtor (whic is the dtor
for all fopen calls) i get these call frames

_not_ calling exit in any($fh);

#0  _file_fopen_dtor (rsrc=0x8420554) at /home/thies/devel/php4/ext/standard/file.c:149
#1  0x08190cbb in list_entry_destructor (ptr=0x8420554) at 
../../php4/Zend/zend_list.c:179
#2  0x0818e65d in zend_hash_del_key_or_index (ht=0x83ae410, arKey=0x0, nKeyLength=0, 
h=1, flag=1)
at ../../php4/Zend/zend_hash.c:543
#3  0x08190a25 in zend_list_delete (id=1) at ../../php4/Zend/zend_list.c:57
#4  0x081a5d70 in _zval_dtor (zvalue=0x8420484, __zend_filename=0x830aa40 
"../../php4/Zend/zend_execute_API.c", 
__zend_lineno=260) at ../../php4/Zend/zend_variables.c:80
#5  0x08193742 in _zval_ptr_dtor (zval_ptr=0x84205a0, 
__zend_filename=0x8316ce0 "../../php4/Zend/zend_variables.c", __zend_lineno=169)
at ../../php4/Zend/zend_execute_API.c:260
#6  0x081a5fcb in _zval_ptr_dtor_wrapper (zval_ptr=0x84205a0) at 
../../php4/Zend/zend_variables.c:169
#7  0x0818e789 in zend_hash_destroy (ht=0x83ae2ec) at ../../php4/Zend/zend_hash.c:572
#8  0x081934f2 in shutdown_executor () at ../../php4/Zend/zend_execute_API.c:164
#9  0x08195a70 in zend_deactivate () at ../../php4/Zend/zend.c:538
#10 0x08089af9 in php_request_shutdown (dummy=0x0) at 
/home/thies/devel/php4/main/main.c:692
#11 0x08085bd3 in main (argc=2, argv=0xb7a4) at 
/home/thies/devel/php4/sapi/cgi/cgi_main.c:790
#12 0x409e3450 in __libc_start_main () from /lib/libc.so.6

as you can see $fp is freed thru the call to
zend_hash_destroy(&EG(symbol_table)); in shutdown_executor.


but not so if i'm _calling_  exit in any($fh);

#0  _file_fopen_dtor (rsrc=0x84205cc) at /home/thies/devel/php4/ext/standard/file.c:149
#1  0x08190cbb in list_entry_destructor (ptr=0x84205cc) at 
../../php4/Zend/zend_list.c:179
#2  0x0818ea00 in zend_hash_apply_deleter (ht=0x83ae410, p=0x8420574) at 
../../php4/Zend/zend_hash.c:627
#3  0x0818ebae in zend_hash_graceful_destroy (ht=0x83ae410) at 
../../php4/Zend/zend_hash.c:678
#4  0x08190e13 in zend_destroy_rsrc_list () at ../../php4/Zend/zend_list.c:234
#5  0x08193591 in shutdown_executor () at ../../php4/Zend/zend_execute_API.c:178
#6  0x08195a70 in zend_deactivate () at ../../php4/Zend/zend.c:538
#7  0x08089af9 in php_request_shutdown (dummy=0x0) at 
/home/thies/devel/php4/main/main.c:692
#8  0x08085bd3 in main (argc=2, argv=0xb7a4) at 
/home/thies/devel/php4/sapi/cgi/cgi_main.c:790
#9  0x409e3450 in __libc_start_main () from /lib/libc.so.6
(gdb) r

as you see the resource is cleaned thru
zend_destroy_rsrc_list which won't work with dependicies.

again the problem is that the arguments on the stack do _not_
get cleared if a function calls exit(). 

what can be done?

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] new/different problem in shutdown

[Thies C. Arntzen]

On Thu, Jul 05, 2001 at 12:06:57PM +0200, [EMAIL PROTECTED] wrote:
> Hello,
> 
> there are also a couple of bug reports filed for this.

could you gimme their no#

re,
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] new/different problem in shutdown

[Thies C. Arntzen]

zeev, andi 

please comment on my attached patch - it fixes my reported
problem!

have i overlooked something?

thanx,
tc

On Thu, Jul 05, 2001 at 11:35:15AM +0200, Thies C. Arntzen wrote:
> 
> zeev,andi
> 
> i have a problem with the oci-extension - it makes heaviy
> usage of ref-counting and creates dependices between resouces
> using refcounts. so i depend on a defined shutdown order and
> i also depend on the complete symbol-table to be destroyed
> before zend_destroy_rsrc_list is called as zend_destroy_rsrc_list 
> won't work with my dependicies. 
> 
> i have created a small testcase that shows my problem without
> using the oci extension: 
> 
> the problem is that if a function calles exit the argumets
> for that function are _not_ destroyed in the shutdown
> mechanism of zend -
> 
> 
>  function any($fh)
> { 
> //exit(); // exit in a function is noo good...
> }
> 
> $fp = fopen("/tmp/1","r");
> any($fp);
> ?>
> 
> if i set a breakpoint in _file_fopen_dtor (whic is the dtor
> for all fopen calls) i get these call frames
> 
> _not_ calling exit in any($fh);
> 
> #0  _file_fopen_dtor (rsrc=0x8420554) at 
>/home/thies/devel/php4/ext/standard/file.c:149
> #1  0x08190cbb in list_entry_destructor (ptr=0x8420554) at 
>../../php4/Zend/zend_list.c:179
> #2  0x0818e65d in zend_hash_del_key_or_index (ht=0x83ae410, arKey=0x0, nKeyLength=0, 
>h=1, flag=1)
> at ../../php4/Zend/zend_hash.c:543
> #3  0x08190a25 in zend_list_delete (id=1) at ../../php4/Zend/zend_list.c:57
> #4  0x081a5d70 in _zval_dtor (zvalue=0x8420484, __zend_filename=0x830aa40 
>"../../php4/Zend/zend_execute_API.c", 
> __zend_lineno=260) at ../../php4/Zend/zend_variables.c:80
> #5  0x08193742 in _zval_ptr_dtor (zval_ptr=0x84205a0, 
> __zend_filename=0x8316ce0 "../../php4/Zend/zend_variables.c", __zend_lineno=169)
> at ../../php4/Zend/zend_execute_API.c:260
> #6  0x081a5fcb in _zval_ptr_dtor_wrapper (zval_ptr=0x84205a0) at 
>../../php4/Zend/zend_variables.c:169
> #7  0x0818e789 in zend_hash_destroy (ht=0x83ae2ec) at ../../php4/Zend/zend_hash.c:572
> #8  0x081934f2 in shutdown_executor () at ../../php4/Zend/zend_execute_API.c:164
> #9  0x08195a70 in zend_deactivate () at ../../php4/Zend/zend.c:538
> #10 0x08089af9 in php_request_shutdown (dummy=0x0) at 
>/home/thies/devel/php4/main/main.c:692
> #11 0x08085bd3 in main (argc=2, argv=0xb7a4) at 
>/home/thies/devel/php4/sapi/cgi/cgi_main.c:790
> #12 0x409e3450 in __libc_start_main () from /lib/libc.so.6
> 
> as you can see $fp is freed thru the call to
> zend_hash_destroy(&EG(symbol_table)); in shutdown_executor.
> 
> 
> but not so if i'm _calling_  exit in any($fh);
> 
> #0  _file_fopen_dtor (rsrc=0x84205cc) at 
>/home/thies/devel/php4/ext/standard/file.c:149
> #1  0x08190cbb in list_entry_destructor (ptr=0x84205cc) at 
>../../php4/Zend/zend_list.c:179
> #2  0x0818ea00 in zend_hash_apply_deleter (ht=0x83ae410, p=0x8420574) at 
>../../php4/Zend/zend_hash.c:627
> #3  0x0818ebae in zend_hash_graceful_destroy (ht=0x83ae410) at 
>../../php4/Zend/zend_hash.c:678
> #4  0x08190e13 in zend_destroy_rsrc_list () at ../../php4/Zend/zend_list.c:234
> #5  0x08193591 in shutdown_executor () at ../../php4/Zend/zend_execute_API.c:178
> #6  0x08195a70 in zend_deactivate () at ../../php4/Zend/zend.c:538
> #7  0x08089af9 in php_request_shutdown (dummy=0x0) at 
>/home/thies/devel/php4/main/main.c:692
> #8  0x08085bd3 in main (argc=2, argv=0xb7a4) at 
>/home/thies/devel/php4/sapi/cgi/cgi_main.c:790
> #9  0x409e3450 in __libc_start_main () from /lib/libc.so.6
> (gdb) r
> 
> as you see the resource is cleaned thru
> zend_destroy_rsrc_list which won't work with dependicies.
> 
> again the problem is that the arguments on the stack do _not_
> get cleared if a function calls exit(). 
> 
> what can be done?
> 
> tc
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


Index: zend_execute_API.c
===
RCS file: /repository/Zend/zend_execute_API.c,v
retrieving revision 1.121
diff -u -r1.121 zend_execute_API.c
--- zend_execute_API.c  2001/06/21 21:17:10 1.121
+++ zend_execute_API.c  2001/07/05 11:14:36
@@ -28,6 +28,7 @@
 #include "zend_ptr_stack.h"
 #include "zend_constants.h"
 #include "zend_extensions.h"
+#include "zend_variables.h"
 #ifdef HAVE_SYS_TIM

Re: [PHP-DEV] new/different problem in shutdown

[Thies C. Arntzen]

On Thu, Jul 05, 2001 at 01:06:43PM +0200, [EMAIL PROTECTED] wrote:
> On Thu, 5 Jul 2001, Thies C. Arntzen wrote:
> 
> > On Thu, Jul 05, 2001 at 12:06:57PM +0200, [EMAIL PROTECTED] wrote:
> > > Hello,
> > >
> > > there are also a couple of bug reports filed for this.
> >
> > could you gimme their no#
> 
> I could only find one: #11895

i don't think they are related - 11895 is an ODBC problem -
am i wrong?
tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Reentrant C scanners for PHP

[Thies C. Arntzen]

On Fri, Jul 06, 2001 at 01:08:03AM +0200, Sascha Schumann wrote:
> This is the first public release of fully reentrant C
> scanners for the PHP language and the INI system.  They
> can be used to replace the Flex-based implementations
> commonly found in the Zend Engine.
> 
> Features:
> 
> - Flexible I/O model; lays groundwork for fully supporting
>   modern web-servers such as Apache 2.0;
> - uses portable C only; significantly improves portability by
>   removing dependence on GNU extensions of C++;
> - fully thread-safe without loss of speed.
> 
> The software is currently available in the form of three
> source files and a patch to the Zend Engine.

where are the .re2c files?

tc


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] new/different problem in shutdown

[Thies C. Arntzen]

On Fri, Jul 06, 2001 at 05:12:07PM +0300, Andi Gutmans wrote:
> Thies,
> 
> I have thought about your problem.  Your patch fixed your test case but it 
> won't fix all test cases. It is pretty much impossible to make sure on 
> bailout (including exit() and errors) that all of the reference counts of 
> the variables will go down to 0 even if we clean the call stack. This is 
> due to necessary internal locking of variables in Zend.

i don't understand why we cant go thru the call-stack and
del-ref all the arguments? we're shutting down anyhow -
right?

also i'm *not talking* about bail at all - bail dosn't work
anyhow - and there's no good way to fix it IMHO. but what
needs to work is calling exit() from a function if there are
resources somewhere on the stack.


> I think we need to think of a better way to handle resource shutdowns 
> (maybe with priorities).

this will be major headache, right?

don't get me wrong, but i need this to get fixed elsewise
using refcounts for dependicies is simply not working and i
would have to think of something different - which would be a
real shame.

tc

> 
> Andi
> 
> At 01:17 PM 7/5/2001 +0200, Thies C. Arntzen wrote:
> >zeev, andi
> >
> >please comment on my attached patch - it fixes my reported
> >problem!
> >
> >have i overlooked something?
> >
> >thanx,
> >tc
> >
> >On Thu, Jul 05, 2001 at 11:35:15AM +0200, Thies C. Arntzen wrote:
> >>
> >> zeev,andi
> >>
> >> i have a problem with the oci-extension - it makes heaviy
> >> usage of ref-counting and creates dependices between resouces
> >> using refcounts. so i depend on a defined shutdown order and
> >> i also depend on the complete symbol-table to be destroyed
> >> before zend_destroy_rsrc_list is called as zend_destroy_rsrc_list
> >> won't work with my dependicies.
> >>
> >> i have created a small testcase that shows my problem without
> >> using the oci extension:
> >>
> >> the problem is that if a function calles exit the argumets
> >> for that function are _not_ destroyed in the shutdown
> >> mechanism of zend -
> >>
> >>
> >>  >> function any($fh)
> >> {
> >> //exit(); // exit in a function is noo good...
> >> }
> >>
> >> $fp = fopen("/tmp/1","r");
> >> any($fp);
> >> ?>
> >>
> >> if i set a breakpoint in _file_fopen_dtor (whic is the dtor
> >> for all fopen calls) i get these call frames
> >>
> >> _not_ calling exit in any($fh);
> >>
> >> #0  _file_fopen_dtor (rsrc=0x8420554) at 
> >/home/thies/devel/php4/ext/standard/file.c:149
> >> #1  0x08190cbb in list_entry_destructor (ptr=0x8420554) at 
> >../../php4/Zend/zend_list.c:179
> >> #2  0x0818e65d in zend_hash_del_key_or_index (ht=0x83ae410, arKey=0x0, 
> >nKeyLength=0, h=1, flag=1)
> >> at ../../php4/Zend/zend_hash.c:543
> >> #3  0x08190a25 in zend_list_delete (id=1) at 
> >../../php4/Zend/zend_list.c:57
> >> #4  0x081a5d70 in _zval_dtor (zvalue=0x8420484, 
> >__zend_filename=0x830aa40 "../../php4/Zend/zend_execute_API.c",
> >> __zend_lineno=260) at ../../php4/Zend/zend_variables.c:80
> >> #5  0x08193742 in _zval_ptr_dtor (zval_ptr=0x84205a0,
> >> __zend_filename=0x8316ce0 "../../php4/Zend/zend_variables.c", 
> >__zend_lineno=169)
> >> at ../../php4/Zend/zend_execute_API.c:260
> >> #6  0x081a5fcb in _zval_ptr_dtor_wrapper (zval_ptr=0x84205a0) at 
> >../../php4/Zend/zend_variables.c:169
> >> #7  0x0818e789 in zend_hash_destroy (ht=0x83ae2ec) at 
> >../../php4/Zend/zend_hash.c:572
> >> #8  0x081934f2 in shutdown_executor () at 
> >../../php4/Zend/zend_execute_API.c:164
> >> #9  0x08195a70 in zend_deactivate () at ../../php4/Zend/zend.c:538
> >> #10 0x08089af9 in php_request_shutdown (dummy=0x0) at 
> >/home/thies/devel/php4/main/main.c:692
> >> #11 0x08085bd3 in main (argc=2, argv=0xb7a4) at 
> >/home/thies/devel/php4/sapi/cgi/cgi_main.c:790
> >> #12 0x409e3450 in __libc_start_main () from /lib/libc.so.6
> >>
> >> as you can see $fp is freed thru the call to
> >> zend_hash_destroy(&EG(symbol_table)); in shutdown_executor.
> >>
> >>
> >> but not so if i'm _calling_  exit in any($fh);
> >>
> >> #0  _file_fopen_dtor 

Re: [PHP-DEV] new/different problem in shutdown

[Thies C. Arntzen]

On Fri, Jul 06, 2001 at 05:39:18PM +0300, Andi Gutmans wrote:
> At 04:31 PM 7/6/2001 +0200, Thies C. Arntzen wrote:
> >On Fri, Jul 06, 2001 at 05:12:07PM +0300, Andi Gutmans wrote:
> >> Thies,
> >>
> >> I have thought about your problem.  Your patch fixed your test case but 
> >it
> >> won't fix all test cases. It is pretty much impossible to make sure on
> >> bailout (including exit() and errors) that all of the reference counts of
> >> the variables will go down to 0 even if we clean the call stack. This is
> >> due to necessary internal locking of variables in Zend.
> >
> >i don't understand why we cant go thru the call-stack and
> >del-ref all the arguments? we're shutting down anyhow -
> >right?
> >
> >also i'm *not talking* about bail at all - bail dosn't work
> >anyhow - and there's no good way to fix it IMHO. but what
> >needs to work is calling exit() from a function if there are
> >resources somewhere on the stack.
> 
> Because as I mentioned there might be locked variables which aren't in the 
> call stack. This is what I could think of right now but there might be 
> other problems too.

could you send me a php-snippet that shows this problem - i'd
like to "dig".
re,
tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] new/different problem in shutdown

[Thies C. Arntzen]

On Fri, Jul 06, 2001 at 07:13:09PM +0300, Andi Gutmans wrote:
> I haven't checked it but something like the following might
> give you a 
> problem.
> 
> Andi
> 
>  function any($fh)
> {
> exit(); // exit in a function is noo good...
> }
> 
> $fp = fopen("/tmp/1","r");
> $fp && any($fp);
> ?>

my patch fixes this as well. (just checked) after looking at
the pzval_lock etc i would suggest moving the
zend_hash_destroy(&EG(symbol_table)); after the 
while (EG(garbage_ptr)--) loop in shutdown_executor.

    am i still missing something?

tc
> 
> 
> At 05:35 PM 7/6/2001 +0200, Thies C. Arntzen wrote:
> >On Fri, Jul 06, 2001 at 05:39:18PM +0300, Andi Gutmans wrote:
> >> At 04:31 PM 7/6/2001 +0200, Thies C. Arntzen wrote:
> >> >On Fri, Jul 06, 2001 at 05:12:07PM +0300, Andi Gutmans wrote:
> >> >> Thies,
> >> >>
> >> >> I have thought about your problem.  Your patch fixed your test case 
> >but
> >> >it
> >> >> won't fix all test cases. It is pretty much impossible to make sure on
> >> >> bailout (including exit() and errors) that all of the reference 
> >counts of
> >> >> the variables will go down to 0 even if we clean the call stack. This 
> >is
> >> >> due to necessary internal locking of variables in Zend.
> >> >
> >> >i don't understand why we cant go thru the call-stack and
> >> >del-ref all the arguments? we're shutting down anyhow -
> >> >right?
> >> >
> >> >also i'm *not talking* about bail at all - bail dosn't work
> >> >anyhow - and there's no good way to fix it IMHO. but what
> >> >needs to work is calling exit() from a function if there are
> >> >resources somewhere on the stack.
> >>
> >> Because as I mentioned there might be locked variables which aren't in 
> >the
> >> call stack. This is what I could think of right now but there might be
> >> other problems too.
> >
> >could you send me a php-snippet that shows this problem - i'd
> >like to "dig".
> >re,
> >tc
> 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [UPDATE] NGScan

[Thies C. Arntzen]

On Mon, Jul 09, 2001 at 08:55:09AM -0700, Rasmus Lerdorf wrote:
> > Especially due to the last point which requires fixing up
> > patches manually every time, I'd like to commit the PHP part
> > of things.  Would anyone object to that?
> 
> I wouldn't object.

same here
tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] NGScan - technical explanation

[Thies C. Arntzen]

On Mon, Jul 09, 2001 at 09:27:17PM +0300, Zeev Suraski wrote:
> I consider it obvious why it makes no sense to abstract the
> scanner input 
> of the engine, and I guess this is not very good - since some of you may 
> not understand what it is about.
> 
> The reason it makes no sense is very simple.  The scanner Sascha wrote 
> doesn't behave in a different way than the current scanner.  Nor does it 
> have any drawbacks when compared to the flex scanner.  It's a replacement, 
> that performs better and is more compatible than the C++ based flex scanner.
> 
> Now, let's imagine someone sent us a new implementation of the DOM-XML 
> module, which has an identical API to the last bit (perhaps with some 
> additions), performs faster, and is more compatible.  Would we add 
> DOM-XML-NG, and let people choose?  Of course not, because it's a plain 
> dumb thing to do.  The old DOM-XML extension will be removed and the new 
> one would take its place.
> 
> The scanner case is similar, except it's a much more fundamental component, 
> which makes even *less* sense to abstract.  Abstracting it gives *nothing* 
> from a technical point of view.  The single reason Sascha did that, was 
> because he is not happy with the Zend Engine license, and doesn't want to 
> submit it the way it is, to make a point.
> 
> I've been discussing the Zend Engine license with the 'leaders' of the 
> German PHP community on Thursday, and with members of the community and the 
> PHP Group on Friday.  As mentioned there, the Zend Engine license is being 
> reviewed, and may change in the next few months.  Especially in the light 
> of this, I see Sascha's changes as making even less sense than what they 
> would have made before, and that wasn't too much to begin 
> with.  Abstracting the scanner buys you *nothing* from a technical point of 
> view.

technical i agree (kinda) - so what should he do:
- not work on it? 
- not even think about digging into the ZendEngine and look
  for possible improvements (and leave all that up to you and
  andi)? 
- put his changes under your QPL?

as long as the (perception of the) Zend License stopps him
from submitting it to the ZendEngine he has no other choice
than to put it somewhere where he feels comfortable with it.

besides that i can actually think of one or two usages for
a scanner in PHP which is not QPL. for exacle that reason the
your DOMXML sample is void - if we had a better DOMXML under
the same license we would use the better one. 

licenses do matter (and yes, i have heard what you said about
the future - and so has sascha -and- he has expressed his
opinion about this issue)

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] [UPDATE] NGScan

[Thies C. Arntzen]

On Mon, Jul 09, 2001 at 09:37:35PM +0300, Zeev Suraski wrote:
> 
> >  So please stop with the personal attacks and
> >concentrate on the real technical issues.
> 
> I'd appreciate it if you stayed out of this one.  I'm fed up with Sascha's 
  

i _really_ dislike this statement!

> attitude towards me and other developers, and decided it was time to point 
> that issue out.

i'm not on IRC - but i do not see how working with sascha has
not always gotten us the "better" result. i do not remember
sascha beeing rude to people - but i do admit that he is
*direct*. that might just be a matter of perception. you - on
the other hand - leave _no_ room for interpretation in this
very situation. 

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] NGScan - technical explanation

[Thies C. Arntzen]

On Mon, Jul 09, 2001 at 09:43:43PM +0300, Zeev Suraski wrote:
> At 21:38 9/7/2001, Thies C. Arntzen wrote:
> >as long as the (perception of the) Zend License stopps him
> >from submitting it to the ZendEngine he has no other choice
> >than to put it somewhere where he feels comfortable with it.
> 
> Yes, but if he puts it in PHP, it also has to be comfortable with other 
> people.  I'm pretty uncomfortable with this structural mess.

you cut a few lines of my mail that were important: i could
see a need for a non-QPL scanner.

> 
> >besides that i can actually think of one or two usages for
> >a scanner in PHP which is not QPL. for exacle that reason the
> >your DOMXML sample is void - if we had a better DOMXML under
> >the same license we would use the better one.
> 
> Can you share your thoughts as to how exactly GPL scanner built into PHP in 
> an odd way would improve your world for the better?  Remember, the scanner 
> is already there, you can use it if you think it's useful.  We're arguing 
> on whether it should be plugged into PHP in a backwards way or not.

the current sources say it's under the PHP-License.

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] NGScan - technical explanation

[Thies C. Arntzen]

On Mon, Jul 09, 2001 at 09:47:46PM +0300, Zeev Suraski wrote:
> Remember that while this is an impressive improvement, it's not all that 
> useful in the vast majority of cases (it's especially useful with Apache 
> 2.0).

IIS comes to mind - aolserver, fasttrack and maybe a few
more.

i don't think you can win thru the technical side here!

tc

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] NGScan - technical explanation

[Thies C. Arntzen]

On Mon, Jul 09, 2001 at 10:11:46PM +0300, Zeev Suraski wrote:
> At 21:48 9/7/2001, Thies C. Arntzen wrote:
> > >besides that i can actually think of one or two usages for
> >> >a scanner in PHP which is not QPL. for exacle that reason the
> >> >your DOMXML sample is void - if we had a better DOMXML under
> >> >the same license we would use the better one.
> >>
> >> Can you share your thoughts as to how exactly GPL scanner built into 
> >PHP in
> >> an odd way would improve your world for the better?  Remember, the 
> >scanner
> >> is already there, you can use it if you think it's useful.  We're arguing
> >> on whether it should be plugged into PHP in a backwards way or not.
> >
> >the current sources say it's under the PHP-License.
> 
> Ok, in which case, can you share your thoughts as to how exactly 
> PHP-license scanner built into PHP in an odd way would improve your world 
> for the better?  Remember, the scanner is already there, you can use it if 
> you think it's useful.  We're arguing on whether it should be plugged into 
> PHP in a backwards way or not.

if i changed the Zend scanner to be able to read obscured
(read encoded so that "joe internet" won't be able to reverse
engineer that) i would have to publish my patch under the
QPL, right? - that would make it even less "secure".

this is nothing i wanna do - but it's a valid argument for
having as much of PHP under the PHP-License as possible IMHO.

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] NGScan - technical explanation

[Thies C. Arntzen]

On Mon, Jul 09, 2001 at 10:00:21PM +0300, Zeev Suraski wrote:
> At 21:55 9/7/2001, Thies C. Arntzen wrote:
> >On Mon, Jul 09, 2001 at 09:47:46PM +0300, Zeev Suraski wrote:
> >> Remember that while this is an impressive improvement, it's not all that
> >> useful in the vast majority of cases (it's especially useful with Apache
> >> 2.0).
> >
> >IIS comes to mind - aolserver, fasttrack and maybe a few
> >more.
> 
> In terms of performance?  I don't recall seeing any production sites 
> running on the threaded version of PHP as of yet, so the extra performance 
> here is not a big issue.  It's especially useful with Apache 2.0 filters 
> because of the way it handles input, which is not applicable with the other 
> servers you mentioned.

i think we can just agree to disagree on this very issue. i
do think that threaded server *do* matter - fullstop.

but this side-thread has not to much to do with the real
subject, so let's end it please.

tc

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]