> On Fri, 2007-10-26 at 10:01 +1300, Amos Jeffries wrote: >> >> > >> >> > 0 - Should not ever happen; requires administrator action >> >> > 1 - Happens once per Squid execution or requests administrator >> >> attention >> >> > 2 - Happens once in a while, unrelated to load >> >> > 3 - Happens once per transaction >> >> > 4 - ... and dumps a lot of data (e.g., request headers) >> >> I considered these 'dumps a lot of data' levels earlier and decided they >> would be better going in the higher levels if there were to be included >> at >> all. >> If anyone wants to debug say a function at your level 5 or 7. They do >> not >> exactly want to wade through the full-dump of request header buffers or >> other objects to find it. > > I think the best approach is to make "dumps a lot of data" a flag that > does not depend on the level. The admin will decide whether they want > the data or not.
Yes I agree with that. > >> >> > 5 - Happens once per I/O or similar regular activity inside >> >> transaction >> >> > 6 - ... and dumps a lot of data >> >> > 7 - Happens several times per I/O or similar (e.g., parsing a >> token) >> >> > 8 - ... and dumps a lot of data >> >> > 9 - Happens a lot, duplicates information, or may not be very >> useful > >> Do you mean each of the current components would become an AsyncJob? >> Great :-) I was wondering at the goal of these recent async commits > > Everything that looks like an asynchronous task, job, logical thread, > etc, will have a chance to become AsyncJob child, get rid of wrappers, > improve debugging, and protect itself from assertions. > >> >> > This may simplify context and >> >> > section management a lot because you would not need to do it in >> every >> >> > method. For example, most "entering..." and "exiting..." debugging >> >> > statements will be gone (moved to a single place). >> >> That may not be such a good idea for the per-function ones. >> having said that, I'm experimenting with details displayed by the HERE >> macro which may replace function-specifics. > > The default debugging is for each async call, not each function. It > includes job state and may even include call arguments. ICAP uses a > prototype of that approach, and I like it a lot. YMMV. I'm a little unsure what you are defining as a 'call' here. You mean a full event loop? or just a class method/API call and everything it references to do its job? Either way after AsyncJob, I think that would add another debug level by itself (job/event/thread start/stop) between component start/stop and function start/stop. Amos
