On Sat, May 22, 2004 at 04:21:02PM -0400, Cliff Woolley wrote: > On Fri, 21 May 2004, Stas Bekman wrote: > > > I understand all that, but I guess I fail to pass the point across. It is > > not > > a problem that I encounter in my code. On the contrary I'm writing tests > > that > > exercise, both valid and invalid ways the API can be called. API that hangs > > when called in invalid way is a problem. Don't you think? > > > > APR_BUCKET_INSERT_BEFORE(fb, db); > > The thing is, it would not be this macro that hangs. All this macro can > do is segfault (if one of the pointers is null, meaning the brigade was > previously corrupted), or do what it's supposed to do (though in doing so > it could potentially corrupt some other brigade, which is what happens > here -- if the bucket being inserted is still in a brigade, as db is, then > that brigade will be corrupted by this operation). The only way to detect > that such corruption will occur is to check the entire ring... that's a > linear time checking operation tacked on to a constant time insertion > operation... not acceptable. :) However, if you compile with bucket > debugging turned on, those validity checks WILL be done.
Perhaps a ``configure'' option for bucket debugging is in order? For that matter, why not make it the default; most folks who build their own APU do so for a development project, so intuitive failure modes will trump efficiency in early use. I can roll a patch, if appropriate.