mhlkmn0108 / junixsocket

Automatically exported from code.google.com/p/junixsocket
1 stars 0 forks source link

Support ECONNABORTED? #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This is not really a bug, more like a question, but I couldn't figure out 
where else to submit it. Can accept() on a AF_LOCAL socket return 
ECONNABORTED? It would seem that no, but I couldn't find it specified 
either way anywhere.

The patch below handles ECONNABORTED in a way consistent with the rest of 
the Java sockets, but I am not sure it is necessary. But may be it is 
better to be safe than sorry?

regards,
Tzvetan

diff --git 
a/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c 
b/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c
index 05d7363..9cb0a20 100644
--- 
a/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c
+++ 
b/src/main/org/newsclub/net/unix/org_newsclub_net_unix_NativeUnixSocket.c
@@ -101,7 +101,11 @@ extern "C" {
 #endif
                ;

-               int socketHandle = accept(serverHandle, (struct sockaddr 
*)&su, &suLength);
+               int socketHandle;
+               do {
+                       socketHandle = accept(serverHandle, (struct 
sockaddr *)&su, &suLength);
+               } while(socketHandle == -1 && errno == ECONNABORTED);
+
                if(socketHandle == -1) {

org_newsclub_net_unix_NativeUnixSocket_throwException(env, strerror(errno), 
file);
                        return;

Original issue reported on code.google.com by tmi...@gmail.com on 4 Dec 2009 at 3:17

GoogleCodeExporter commented 9 years ago
Sorry for the formatting of the patch :-) Blame the Google interface...

Original comment by tmi...@gmail.com on 4 Dec 2009 at 3:19

GoogleCodeExporter commented 9 years ago
I have not found any reference on ECONNABORTED for Unix Domain Sockets. 
Apparently,
it has not occurred so far.

If it would really happen with the current code, an AFUNIXSocketException would 
be
thrown. It would be the responsibility of the user to handle it.

With the proposed patch it could happen that we loop indefinitely in native code
(imagine ECONNABORTED being set for each call to accept), which is not what we 
want
either.

I suggest to not consider it as a problem until it occurs the first time (which 
we
can then try to reproduce and test new code against it).

Original comment by ckkohl79 on 4 Dec 2009 at 9:14

GoogleCodeExporter commented 9 years ago
Well, it is handled by looping like this in the regular socket code and it 
makes 
sense to me. If it is a blocking accept(), ECONNABORTED is just an event which 
should 
be ignored. Looping indefinitely is not a problem - it is what we want, since 
it is a 
blocking operation. 

About handling it in user code - the problem is that the user code has no 
robust way 
of identifying the exact error that occurred. It can examine the error message, 
but 
that is probably not portable. Plus, if we assume that really ECONNABORTED can 
occur, 
that would be breaking the contract of accept().

Anyway, as I said I am not convinced myself that it is needed - with AF_LOCAL 
there 
is no 3-way handshake and that is the only way ECONNABORTED can occur. I am OK 
if you 
leave things as they are, but I just wanted to raise this possible issue.

(Is there a better way to discuss minor things like this which come up 
occasionally, 
instead of submitting bug reports? I have another subtle technical question.)

regards,
Tzvetan

Original comment by tmi...@gmail.com on 4 Dec 2009 at 4:02

GoogleCodeExporter commented 9 years ago
Marking this as wontfix. Please re-open when you actually get an ECONNABORTED 
in the
wild.

Original comment by ckkohl79 on 22 Apr 2010 at 5:48