On June 6, 2007 1:14:22 PM -0700 Adam Bennett <[EMAIL PROTECTED]> wrote:
Rant aside, let me take a stab at your question. It looks like ne_get is a synchronous call. If it is successful the data should be sitting at the end of fd so you could rewind your file pointer and read until EOF. Does that help at all?
No, the problem is that you never get EOF. neon does the right thing in that it does not close the fd (as Joe said, because it doesn't open it in the first place). This works fine if you are (say) writing to a file. But I create a pipe and have ne_get() write to that. After calling ne_get() I read() from the pipe and parse the web server response. (I'm using a simplistic http API for RPC ... which is out of my control.) What I'm worried about is that the web server is misbehaving and sends a short response. Now that I think about it, a correct response is always less than PIPE_BUF bytes so even if I get a short response, I am guaranteed to have read the whole thing. But if the response is too long, the problem is then that my next read() will pull in some of the old data (assuming I use the same fd). For example, the initial part of the web server response might be correct and my app parses it, but the web server sends a lot of extra garbage after it. After a subsequent ne_get(), my next read() won't get the correct data. I guess this is fixable by using a new fd, but I like general purpose, correct, fixes rather than what I consider to be a workaround. -frank _______________________________________________ neon mailing list [email protected] http://mailman.webdav.org/mailman/listinfo/neon
