i was more concerned that we not lose track of awaiting data because
of not retrying, but i'm woefully uninformed on how poll()/epoll do
their thing at this point.
the solution you chose (in later email) seems good to me.
rob
On Dec 11, 2007, at 10:52 AM, Sam Lang wrote:
That seems possi
[EMAIL PROTECTED] wrote on Tue, 11 Dec 2007 10:24 -0600:
> From a practical perspective, this seems to work, and an implementation
> that has poll telling us that bytes are ready, but recv returning
> EWOULDBLOCK because of anything other than small timing issues in the
> kernel seems broken any
That seems possible. I did some reading and couldn't find any obvious
reasons the kernel does this, but I think the basic answer is that it
doesn't break the semantics of recv, as there aren't any semantic
guarantees between results from poll and calls to recv. To
investigate further I
I agree Pete -- its messy. Just by the names of errnos, it seems
appropriate to return what's been completed if we get EWOULDBLOCK,
while EAGAIN suggests we can just call recv again and get what we
want. But as you point out they're the same value. According to the
opengroup, impls _ma
[EMAIL PROTECTED] wrote on Mon, 10 Dec 2007 21:19 -0600:
> while a loop will fix it, it would be really nice to understand how we get
> EAGAIN when we think that there are bytes there...
[..]
> On Dec 7, 2007, at 4:55 PM, Sam Lang wrote:
>> I'm seeing recv on a socket in non-blocking mode returnin
while a loop will fix it, it would be really nice to understand how
we get EAGAIN when we think that there are bytes there...
rob
On Dec 7, 2007, at 4:55 PM, Sam Lang wrote:
I'm seeing recv on a socket in non-blocking mode returning EAGAIN
occasionally, even though epoll has just told us
I'm seeing recv on a socket in non-blocking mode returning EAGAIN
occasionally, even though epoll has just told us there's bytes
waiting. I guess that's why the call was initially a blocking recv.
I can add a loop around the non-blocking recv while it returns EAGAIN,
unless someone can
sounds good to me. -- rob
Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Tue, 16 Oct 2007 16:47 -0500:
Thanks Pete. Hopefully we've got all sockets in non-blocking mode
now. Incidentally, the blocking calls in sockio.c aren't used
anymore, and since brecv doesn't actually leave the socket
[EMAIL PROTECTED] wrote on Tue, 16 Oct 2007 16:47 -0500:
> Thanks Pete. Hopefully we've got all sockets in non-blocking mode
> now. Incidentally, the blocking calls in sockio.c aren't used
> anymore, and since brecv doesn't actually leave the socket in the
> same state it started, I'm temp
Thanks Pete. Hopefully we've got all sockets in non-blocking mode
now. Incidentally, the blocking calls in sockio.c aren't used
anymore, and since brecv doesn't actually leave the socket in the
same state it started, I'm tempted to remove or deprecate those
blocking functions altogethe
[EMAIL PROTECTED] wrote on Tue, 16 Oct 2007 16:54 -0400:
> Update of /projects/cvsroot/pvfs2/src/io/bmi/bmi_tcp
> In directory parlweb1:/tmp/cvs-serv25077/src/io/bmi/bmi_tcp
>
> Modified Files:
> bmi-tcp.c sockio.c
> Log Message:
> switching from the blocking receive (where we had just done
11 matches
Mail list logo
