On 16 Jul 2009, at 09:36 , Sven Eckelmann wrote:
Maybe someone sees a problem in my proposal. The only thing I see is that the read should appear before locking the current buffer or a "bad person" (me) could delay the new buffers for all others by connecting and then wait for a long time. I see the same problem in your current implementation.
I'm not sure the current implementation performs a read between locks but I agree that the server should not block other connections while waiting for a response from another connection.
I didn't wanted to say that the current implementation in trunk uses a read, but Jonathan Mzengeza's patch does it.
It _is_ Jonathan's patch I'm referring to :-)
As it stands his code does not delay the new buffers for all others if someone connects and then waits a long time.
But that is a choopchick and not really important one way or another, I think we both agree that switching to blocking sockets is a promising idea.
Does anyone with insights into the gooey innards of vis.c have any thoughts about this strategy?
- a