On 04/12/2018 02:22 PM, Nodiv Byzero wrote: > The point is that there are few places where config_load() gets called > in the sequential order (the same request) and every time it loads and > parses data.
Are these also places where if (!isset($AUR_CONFIG)) fails to actually fulfill its sole reason to exist? Not that it matters... if for some reason we are loading the config very fast and scribbling over each other, because $AUR_CONFIG is not yet set when we begin the second config_load() execution, checking if $config is already loaded won't help -- it's a local variable. So, question: can you show me code where $config would *not* be `false`? Because I think this proposition would be either a no-op or a reason to file a severely major upstream php bug complaining that the variables are leaking all over the floor. ... That being said, yes, there is a race condition where you call config_load() twice, and they both set $AUR_CONFIG. Elevating $config and $default_config to globals, *then* using them as additional file access caches to micro-optimize one or two disk ops, seems wasteful to me. It's not like this is being run in a tight loop. If any effort should be spent to fix this, rather than introducing painful, non-obvious code, we should introduce some sort of proper cache. -- Eli Schwartz Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
