On Tue, Aug 13, 2002 at 08:44:21AM +0400, kuznet@xxxxxxxxxxxxx wrote:
> Hello!
>
> > it returns -EISCONN. This behavior is consistent in all operating
> > systems which I have tested, which include the following:
>
> This is very strange. Linux should return success once.
>
> Probably, I should explain why I ask this. This is a necessary
> element of implementation of restartable connect(). If connect()
> is restarted after signal, it should return success on connected
> socket sometimes rather than -EISCONN.
>
I see.
Possibly, I should be a bit clearer, to make sure that I am not
not confusing with what are you are asking for.
The summaries so far, for Linux:
(1) no signals (so it runs the sighandler but doesn't return from the
sys call until it completes), non-blocking socket:
-EINPROGRESS, -EALREADY, -EISCONN, in that order. Never returns 0.
(2) SIGALRM, set for 1 second, (and reschedules another for 1 second),
non-blocking
-EINPROGRESS, -EALREADY, -EISCONN, in that order. We note that in
-EALREADY a signal is processed. That is the SIGALRM handler.
(3) SIGALRM, blocking:
will run sighandler but connect() returns 0 once, running connect()
again gives EISCONN.
Is that what you expected?
>
> > On Linux (v 2.4.18):
> >
> > read() returns 0 with an errno of 115. On Linux 115 corresponds to
> > -EINPROGRESS.
>
> I am sorry, this machine is not running Linux.
>
> Zero length read() always returns zero, not depending of socket state.
>
>
It doesn't seem to be standardized what one should return.
So read() / write() is not a portable way to test if a socket has been
connected with non-blocking connect.
-- G.
|