On Thu, Nov 15, 2007 at 09:47:46 -0800, dormando wrote: > Sure, I guess it's a great way to OOM the machine (I'd be very impressed > if someone actually did this!) since iov bytes aren't presently limited > by anything, but it doesn't presently deadlock like you say it does.
Hmm, maybe I don't get the code, but I think the server may switch from conn_write to conn_read only on TRANSMIT_COMPLETE, i.e. it pushes full responce before reading the next request. The test case could tell, but lazy to write one. > But what about the suggestion steven had? A per connection silent > on/silent off flag? If silent's on you can just drop the data instead of > copying it into an iovec in a few places, and leave the rest of the code > alone. If 'reply' and 'noreply' commands are mixed, it seems like an unnecessary overhead to wrap a single command with on/off. OTOH for a bunch of commands 'noreply' in every of them is an overhead. Still, per-command parameter better suits for libraries with one binding per command. So on/off might have its uses, but kinda orthogonal to 'noreply'. -- Tomash Brechko
