Subject | Re: [firebird-python] Problem with tracing and FDB |
---|---|
Author | Pavel Cisar |
Post date | 2013-10-24T08:35:42Z |
Hi,
Dne 24.10.2013 10:09, Harriv napsal(a):
then :) There so no "interactive" mode. Once trace session is started,
Firebird engine accumulates trace report strings in internal buffer (if
there are any according to your trace config) until it's full (then no
more trace data is accumulated until client empties it enough for new
data via isc_service_query call). Client calls isc_service_query API
call that BLOCKs, i.e. returns only when there is any content in
engine's output buffer and trace session is active. So if there is
nothing to return, client is "frozen".
So handling trace sessions typically require two processes or threads,
one that starts the session, reads output in loop and does something
with it (prints out, store to file, whatever) and second one to end the
session. You can also terminate the trace session in "reading"
process/thread, for example using timer or other way to interrupt it and
tell it to stop fetching trace output, but that will react *only* when
it's outside of isc_service_query call, hence two processes is more
"interactive" or better "resposive".
best regards
Pavel Cisar
IBPhoenix
Dne 24.10.2013 10:09, Harriv napsal(a):
>Well, it seem that you have misunderstood how trace in Firbeird works
>
> I got forward:
>
> If I STOP the trace session started from FDB with fbtracemgr.exe,
> svc.readline() will return all(?) trace data stored in some buffer. So
> what I really am looking for is how get "interactive" mode?
then :) There so no "interactive" mode. Once trace session is started,
Firebird engine accumulates trace report strings in internal buffer (if
there are any according to your trace config) until it's full (then no
more trace data is accumulated until client empties it enough for new
data via isc_service_query call). Client calls isc_service_query API
call that BLOCKs, i.e. returns only when there is any content in
engine's output buffer and trace session is active. So if there is
nothing to return, client is "frozen".
So handling trace sessions typically require two processes or threads,
one that starts the session, reads output in loop and does something
with it (prints out, store to file, whatever) and second one to end the
session. You can also terminate the trace session in "reading"
process/thread, for example using timer or other way to interrupt it and
tell it to stop fetching trace output, but that will react *only* when
it's outside of isc_service_query call, hence two processes is more
"interactive" or better "resposive".
best regards
Pavel Cisar
IBPhoenix