If I can chime in with my 5 cents,
On 15 Jul 2009, at 20:50 , Sven Eckelmann wrote:
Thanks, is this better?
There are different things I don't understand complete. How does the receive buffer affect the output buffer in this case?
Without spending a day rooting through the syscall implementation I'm not sure why this is the case. Neither the documentation nor Google has been much help beyond revealing that:
* It is a widespread phenomena where writes are getting truncated when there is unread data on the socket.
* There exists many opinions and precious little consensus on the precise semantics of read(2) and write(2) !
Oy vey.
Isn't it possible to disable non-blocking sockets in vis.c:635-638 and change the read to following for json: Try to recv data until the read fails or an empty line (please check HTTP rfc before implementing) appears. If the read fails -> discard everything. If the empty line appeared then send the data. You should create an extra function to read (and discard) the header stuff.
If everyone else thinks this is a good idea I would also greatly prefer to modify the vis server to use blocking sockets.
Given that it is a threaded implementation it is not immediately obvious to me why this approach was chosen originally unless the threading got added later?
Thoughts anyone?
My personal opinion about the errno and delay stuff is... I don't like it. It seems to be somewhat correct to ask again on EAGAIN corresponding to the man page, but we could do it in a cleaner way if possible.
*nod*
It _is_ ugly. It is simulating blocking behavior on a non-blocking object which, really, means that one should ideally just be using a blocking object in the first place!
:-D
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.
Thank you for the code review Sven!
- antoine
-- http://7degrees.co.za "Libré software for human education."