On Fri, Dec 25, 2009 at 11:26 AM, Andy Shellam <andy-lists@xxxxxxxxxxxxxx>wrote: > Hi, > > Have you taken a look at Xdebug - http://xdebug.org/ ? > > From the manual: "Xdebug allows you to log all function calls, including > parameters and return values to a file in different formats." > > Would this do what you need - then your second script could process this > file? > > Regards, > Andy > > Well, after installing PECL APD, i found that the parameters listed @ http://nl3.php.net/manual/en/function.apd-set-pprof-trace.php are incorrect. Without a guessing game, apd_set_pprof_trace() won't do it's work at all. So i'll have a look at xdebug between the festivities of these days.. Thanks for the tip. I'll probably still have the concurrency problem though (lots of data being written to disk, read from disk by another thread, and expecting such an arrangement to keep up with real-time). It's usually a recipe for disaster. But it'd be soooo cool to fire off multiple "threads" from any php function(1) and see the functions being called in various threads pop up in my ajax debugger, with details of any call shown on-mouse-over. Interesting sub-threads (aka: the ones that produce anomalies) would stay listed, successfull subthreads would fairly quickly disappear from view. The one solution i have to avert said disasters is to maintain a pointer for: - whatever my own logging format has "absorbed" from the xdebug log file (for the current operation) - whatever the browser has read/absorbed from my own logging format. By timestamping all the entries, i can at least get my ajax debugging wonder to correctly display all that has happened in very-recent times for my operation. It'll lag, but i'm hoping i can avert any of the "disasters" that have plagued me in the past when processing large data sets "through a disk". (1)=(by doing $h[$num]=fopen($urlOnMyOwnServer), and then fread($h[$num], 2048) in a loop, processing results when feof($h[$num])===true )
