You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2010/08/26 12:06:08 UTC
Re: svn commit: r989443 - /apr/apr/trunk/file_io/win32/pipe.c
On Thu, Aug 26, 2010 at 1:02 AM, <mt...@apache.org> wrote:
> Author: mturk
> Date: Thu Aug 26 05:02:33 2010
> New Revision: 989443
>
> URL: http://svn.apache.org/viewvc?rev=989443&view=rev
> Log:
> Loop if the recv gets WSAEWOULDBLOCK
>
ordinarily I'd think loop-while-EWOULDBLOCK would be an undesirable busy
loop
why is this a special case?
>
> Modified:
> apr/apr/trunk/file_io/win32/pipe.c
>
> Modified: apr/apr/trunk/file_io/win32/pipe.c
> URL:
> http://svn.apache.org/viewvc/apr/apr/trunk/file_io/win32/pipe.c?rev=989443&r1=989442&r2=989443&view=diff
>
> ==============================================================================
> --- apr/apr/trunk/file_io/win32/pipe.c (original)
> +++ apr/apr/trunk/file_io/win32/pipe.c Thu Aug 26 05:02:33 2010
> @@ -321,7 +321,11 @@ static apr_status_t create_socket_pipe(S
> }
> /* Verify the connection by reading the send identification.
> */
> - nrd = recv(*rd, (char *)iid, sizeof(iid), 0);
> + do {
> + nrd = recv(*rd, (char *)iid, sizeof(iid), 0);
> + rv = nrd == SOCKET_ERROR ? apr_get_netos_error() :
> APR_SUCCESS;
> + } while (APR_STATUS_IS_EAGAIN(rv));
> +
> if (nrd == sizeof(iid)) {
> if (memcmp(uid, iid, sizeof(uid)) == 0) {
> /* Wow, we recived what we send.
> @@ -337,7 +341,6 @@ static apr_status_t create_socket_pipe(S
> }
> }
> else if (nrd == SOCKET_ERROR) {
> - rv = apr_get_netos_error();
> goto cleanup;
> }
> closesocket(*rd);
>
>
>
--
Born in Roswell... married an alien...
Re: svn commit: r989443 - /apr/apr/trunk/file_io/win32/pipe.c
Posted by Mladen Turk <mt...@apache.org>.
On 08/26/2010 12:06 PM, Jeff Trawick wrote:
> On Thu, Aug 26, 2010 at 1:02 AM, <mturk@apache.org <ma...@apache.org>> wrote:
>
> Author: mturk
> Date: Thu Aug 26 05:02:33 2010
> New Revision: 989443
>
> URL: http://svn.apache.org/viewvc?rev=989443&view=rev <http://svn.apache.org/viewvc?rev=989443&view=rev>
> Log:
> Loop if the recv gets WSAEWOULDBLOCK
>
>
> ordinarily I'd think loop-while-EWOULDBLOCK would be an undesirable busy loop
>
> why is this a special case?
>
We already have a data written in the loopback adapter,
and in 99% of the cases data is already there so the
WSAEWOULDBLOCK would never get returned.
However if running as VM guest with 2+ cores, it can have a single
recv returning EWOULDBLOCK. I did some profiling and
the second call to the recv always return the required
data, so at max there is 2 recv calls.
Regards
--
^TM