David Reid wrote:
Following on from Sander & Ian's work on adding debug code to the pools, is there any reason this can't be extended across to APR in general? Jeff has recently posted to httpd about a problem he's been having and has a patch that he doesn't really want to go into APR for adding some interesting debugging, but really the problem is more complex than that isn't it?
We should have some way of getting OS relevant debugging information out from APR for hte various "sub" sections, probably along the same lines as the pool debug stuff just committed. I say OS relevant as there's no point having general output where we differ so wildly in the types of certain key things we'd want to see (fd == int on unix, handle on win32 and so on).
If we agree then shall we start with one particular section, say network_io as this is potentially one of our biggest and most problematic areas?
david
I suggested something very similiar to what was done on the pool code to be applied to the bucket code. I think the general feeling was that people didn't like the #ifdefs everywhere. (cliff also mentioned it would be better to track the bridage movement not creation)
I'm +1 for the idea on brigade, and pools ops as I think they are difficult to get correct for a module developer not intimate with the library.
I think the network/file I/O should be done, but this should be at a different debug level for the library developers to use, possibly even with a 'replay' function which could re-read the output file and play it back through the original application so you could playback a segfault/incorrect (or is that WAY too hard)
