Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6122
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Wed, 3 Dec 2003 18:15:02 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <276764937.20031203181502@marcus-boerger.de>
To: Uwe Schindler <uwe@thetaphi.de>
Cc: jay@php.net, internals@lists.php.net
In-Reply-To: <6.0.1.1.0.20031203175354.039cac08@127.0.0.1>
References: <6.0.1.1.0.20031203175354.039cac08@127.0.0.1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] browscap and nesting level too deep (bug #25916)
From: helly@php.net (Marcus Boerger)

Hello Uwe,

Wednesday, December 3, 2003, 6:06:13 PM, you wrote:

> Today I got the error from bug #25916 several times on our webserver. 
> Looking through the code I found out the following:
> * It depends NOT on the fact if there is a parameter to get_browser() or not
> * It happens sometimes when server is very heavy loaded, the homepage of 
> the domain uses the get_browser() function and is the most visited page.

> So it must be a multithreading issue (NSAPI is a multithreading webserver).
> And I have an idea:
> Line 257 uses:
>          zend_hash_apply_with_arguments(&browser_hash, (apply_func_args_t)
> browser_reg_compare, 2, lookup_browser_name, &found_browser_entry);

> This is the only function in this context in zend_hash.c which uses the 
> Recursion protection with
> #define 
> HASH_PROTECT_RECURSION(ht) 
> \
>          if ((ht)->bApplyProtection) 
> { 
> \
>                  if ((ht)->nApplyCount++ >= 3) 
> { 
> \
>                          zend_error(E_ERROR, "Nesting level too deep - 
> recursive dependency?");          \
>                  } 
> \
>          }

> The browser hashtable is a global variable in browscap.c and can be used by
> more than one call to get_browser() even at the same time. So if one 
> zend_hash_apply_with_arguments() locks the hashtable and a second and third
> thread tries to do that you will get the error, because (ht)->nApplyCount++
> raises and raises...

> This evening I will try to put a mutex at the beginning of get_browser to 
> prevent more threads running at the same time there. But as I see this, 
> this zend_hash_apply function is used very often could there be other 
> effects if a global variable is a hashtable?

> Only one question: Is there a special PHP way to use mutexes? I am not 
> familar in Zend programming (I do only SAPI...)

Why not simply use external iteration? You don't add or modify the browser
list right?


-- 
Best regards,
 Marcus                            mailto:helly@php.net