On Fri, Dec 25, 2009 at 11:26 AM, Andy Shellam <andy-li...@networkmail.eu>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
- 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

(1)=(by doing $h[$num]=fopen($urlOnMyOwnServer), and then fread($h[$num],
2048) in a loop, processing results when feof($h[$num])===true )

Reply via email to