Hello!
I thought I'd drop a brief note and let everyone, especially you Paul,
know that I've updated the project pages for One-Wire applications and
their problems. All of this is hosted at http://www.gregg.levine.name
.
Since relocating the site to a new hosting entity on 31 March, I have
noticed
You get a return code of 0 on recv() only if the connection peer has
closed. If you try to send() to the socket you should get an EPIPE as
well as a SIGPIPE (unless you masked it off in the send option flags).
You need to check for closed connections on both send() and recv()
wherever they are
No, the file is opened with a standard socket command, and we use
threads rather than non-blocking io to
permit assynchronous communications.
It's rather tedious, but this is the best I could code for using fcntl
rather than MSG_DONTWAIT.
// Check if the server closed the connection
Paul,
This seems good. One remaining issue might be portability.
MSG_DONTWAIT is a linux extension, according to the man page. The
alternative is to set the socket to non-blocking mode first. I'm not
sure if it already is...
Thanks.
~Jacob
On Tue, 16 Nov 2010 12:32:13 -0500
Paul Alfille wrote
Ok, this is the patch so far. It's possible that an connection that
causes an error would be
caught when the write is attempted, but it's easy to test here and, I
agree, looks more
resilient.
// Check if the server closed the connection
// This is contributed by Jacob Joseph to fix
On 11/16/2010 12:21 PM, Paul Alfille wrote:
> I could test for errno = EAGAIN or EWOULDBLOCK in that case, or is
> this all unnecessary?
I think that closing the connection if recv() returns an error is worth
doing. Makes the code more resilient.
Cheers,
Eloy Paris.-
-
Hi Jacob,
On 11/16/2010 12:08 PM, Jacob Joseph wrote:
> Paul,
> I don't think that works. recv() returns -1 when there's no data to
> read.
It returns -1 when there's not data to read and the socket is in
non-blocking mode. But in that case errno is set to EAGAIN or
EWOULDBLOCK, so there shou
I could test for errno = EAGAIN or EWOULDBLOCK in that case, or is
this all unnecessary?
On Tue, Nov 16, 2010 at 12:08 PM, Jacob Joseph wrote:
> Paul,
> I don't think that works. recv() returns -1 when there's no data to
> read.
>
> ~Jacob
>
> On Tue, 16 Nov 2010 11:54:45 -0500
> Paul Alfille w
Paul,
I don't think that works. recv() returns -1 when there's no data to
read.
~Jacob
On Tue, 16 Nov 2010 11:54:45 -0500
Paul Alfille wrote:
> Wou7ld modifying your patch to:
> if (recv(scs->file_descriptor, test_read, 1, MSG_DONTWAIT |
> MSG_PEEK) <= 0) { be appropriate to catch recv e
Wou7ld modifying your patch to:
if (recv(scs->file_descriptor, test_read, 1, MSG_DONTWAIT | MSG_PEEK)
<= 0) {
be appropriate to catch recv errors as a "close connection" condition?
Paul Alfille
On Mon, Nov 15, 2010 at 4:58 PM, Jacob Joseph wrote:
> Oops. I introduced a typo while makin
Bump...anyone ever hit this problem?
In production, it's not a big deal right now, but a working ow.finish()
would be nice for unit testing.
j
On Monday 01 November 2010, Joshua J. Kugler elucidated thus:
> Given the following code:
>
> import sys
> import ow
>
>
> def tree( sensor ):
> pri
11 matches
Mail list logo
