Re: Checking for closed/broken connections

Alwin a écrit :

> And therefore I found a (possible) problem inside mailstream_socket.c (see
> patch appended)

did you reroute SIGPIPE ?

> > - on some systems the tcp/ip environment will give a segfault when you try to
> read from a socket not marked as readable or it ends in a endless read 'cause
> you have the socket marked as blocking (why?)

you can set a mailstream_delay (or such thing like that) to set the delay.

> -tcp/ip file-descriptors I think checking for exceptions is a good idea. There
> are such a lot of thing can going wrong...

is this an alternative to sigpipe ?

> - on most systems an application crashes trying writing on a socket not
> writeable (there are a lot of reasons for that possible).

For example, when the socket is closed on the other side ?

> I think, you should
> check for that. In most times select will return immediately 'cause most
> sockets are writeable. But... its tcp/ip :) Means, I believe it would be
> better to check for write and exceptions via select (as made in the patch).

Then, I am waiting for further explaination about this (see my question).

> Why not using recv/send on tcp/ip sockets? In most cases it should be have a
> little better handling for that as pure read/write.

it is the same.

> And why blocking sockets? it is a real problem: on smart devices you can easy
> lose the connection. In that case read/write hangs. forever in blocking mode
> and we have to kill the application. may be, that blocking sockets have a
> better handling to the programmer... but from users point of view.... Or is
> there something I didn't see or not understand the right way?

you can use the delay.

I use select() to workaround the delays.

-- 
DINH Viet Hoa



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn