I replied on a different thread, but I was the one who implemented the ring buffer. Whatever you do, don't use the "yield" solution as that will reintroduce the DoS vulnerability that the ring-buffer was added to fix.
If you really don't like the ring-buffer than the fix would be to use a resizeable queue of some sort, and I guess I could do that, but then you are back to 1.7.x where streaming data quickly from a handler chews up m2 RAM like crazy. The real fix is to add a way for m2 to throttle backends and the closest we have to that now is read/write stats from the control port, which is a bit primitive. -Jason On 11:01 Wed 22 Aug , Jeff Van Voorst wrote: > On 8/22/12 10:52 AM, Scott Reynolds wrote: > > > > So I meant to try a patch for this and didn't get to it. What I was > > thinking was a change to the enqueue method. While the pending > > messages is equal to the ring size, libtask yield. What this should do > > is cause the delivery task to execute and remove messages from the ring. > > > Is there good documentation for libtask or is the libtask used by > mongrel2 basically the same as the documentation available at > http://swtch.com/libtask/ (Russ Cox's libtask)? > > I have a vague idea of coroutines, and could try patching it myself. > The primary issue is trying to grok the scheduling of tasks and knowing > how execution of tasks is ordered. As background, I am best familiar > with the event loop provided by libev. > > --Jeff >
