Hi list, I want to report an issue I encountered with bucket brigades. It's not really a bug - more some kind of complicated handling which is not documented.
This mail might be a little lengthy, but I'd really appreciate if you could take the time to read and comment on this. My situation is as follows: I'm writing an Apache module which holds some number of persistent connections to a backend server and hands them out to each request (via an apr_reslist). The reslist holds sockes and bucket brigades with a socket bucket in it (allocated on the child pool). Now when I'm in a request and aquired a resource (socket + brigade) from the reslist, I read with apr_brigade_split_line from the brigade into a brigade allocated from the request pool. Afterwards, I return as soon as possible the resource back to the reslist to allow other requests to use the backend server. I guess you can already imaginge what happens next. I painfully found out by digging through the APU sourcecode. The bucket in the request-local brigade holds a reference to the original bucket of the brigade in the reslist, effectively messing with the ref-counter spuriously. What I complain about (no offense) is, that this is not documented. For someone who isn't deeply into the sourcecode, this is really frustrating, as one (IMHO) would expect that the two brigades are independent in terms of thread safety after a call to apr_brigade_split_line. My feedback for improvement would be to point these issues out in the documention. Regarding this and trying to work around the problem, I found no possibility to decouple the two brigades. Maybe I'm missining something, but as far as I see a copied bucket is still allocated on the source bucket_allocator. While I understand that ref-counting and cheap copying is crucial for performance, I'd also would like to see functions deep-copying buckets (as long as this is applicable - e.g. for heap buckets). If I just missed the function for this, I'd be glad if you could let me know. Regards, Edgar -- "Edgar Frank" <[email protected]>
