When testing on a solaris box, the server side
would get a -1 on the socket, if a block was split.
The errno was 4 (EINTR). The code would think
that the connection was broken and close down.
This patch adds EINTR to the list of wouldblock
errnumbers.
With this patch, I have got communication between
the solaris box and the linux box!!
I dont know whats going on with solaris, I have another patch from some one claiming to get ENOENTs there. At this rate I'll end up just ignoring any error return on solaris.
I haven't noticed any problems with solaris here, but I'll take a look. If I can resolve this I will release 0.6.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, this is incorporated into cvs. Apparently EINTR will be generated by some user-space threads libraries that use signals to implement task switching or by multithreaded/multiprocess apps that use signals to communicate between threads.
If the signal isn't fatal, there doesn't seem to be any reason to give up on the rpc. There does seem to be some question as to whether any data has been read/written if you get EINTR but we'll see whether that becomes an issue...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When testing on a solaris box, the server side
would get a -1 on the socket, if a block was split.
The errno was 4 (EINTR). The code would think
that the connection was broken and close down.
This patch adds EINTR to the list of wouldblock
errnumbers.
With this patch, I have got communication between
the solaris box and the linux box!!
*** src/XmlRpcSocket.cpp 2003-02-13 04:01:09.000000000 +0000
--- sol-socket/XmlRpcSocket.cpp 2003-02-19 16:52:50.000000000 +0000
***************
*** 180,186 ****
s.append(readBuf, n);
} else if (n == 0) {
*eof = true;
! } else if (err == EINPROGRESS || err == EAGAIN || err == EWOULDBLOCK) {
wouldBlock = true;
} else {
return false; // Error
--- 180,188 ----
s.append(readBuf, n);
} else if (n == 0) {
*eof = true;
! } else if (
! err == EINPROGRESS || err == EAGAIN || err == EWOULDBLOCK || err == EINTR)
! {
wouldBlock = true;
} else {
return false; // Error
I dont know whats going on with solaris, I have another patch from some one claiming to get ENOENTs there. At this rate I'll end up just ignoring any error return on solaris.
I haven't noticed any problems with solaris here, but I'll take a look. If I can resolve this I will release 0.6.
OK, this is incorporated into cvs. Apparently EINTR will be generated by some user-space threads libraries that use signals to implement task switching or by multithreaded/multiprocess apps that use signals to communicate between threads.
If the signal isn't fatal, there doesn't seem to be any reason to give up on the rpc. There does seem to be some question as to whether any data has been read/written if you get EINTR but we'll see whether that becomes an issue...