Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[ace-users] EAGAIN vs. EWOULDBLOCK

188 views
Skip to first unread message

Nickolai Dobrynin

unread,
Apr 4, 2007, 6:39:01 PM4/4/07
to ace-...@cse.wustl.edu
Hi,

I have a non-blocking TCP socket of type ACE_SOCK_Stream, and I was wondering if there is a cross platform way to check
whether the 'recv' operation would block.  I tried Google-ing and came across all kinds of controversy around this issue.  On some
platforms, It appears, these two are assigned the same numerical value, where as on others one or the other may not even
exist or be assigned different values.

Would it be correct to say that, for non-blocking sockets, both EAGAIN and EWOULDBLOCK represent the exact same error?
If so, is there any facility ACE has that performs this check?  Something like "bool would_block(...)".


Many thanks,

Nickolai Dobrynin

Doug Schmidt

unread,
Apr 4, 2007, 6:49:00 PM4/4/07
to ndob...@gmail.com, ace-...@cse.wustl.edu
Hi,

I don't think EAGAIN and EWOULDBLOCK necessarily have the same value. I believe ACE tries to use EWOULDBLOCK for everything to ensure consistency.

Doug

Hi,


Many thanks,

Nickolai Dobrynin
_______________________________________________
ace-users mailing list
ace-...@mail.cse.wustl.edu
http://mail.cse.wustl.edu/mailman/listinfo/ace-users


Steve Huston

unread,
Apr 4, 2007, 6:47:58 PM4/4/07
to Nickolai Dobrynin, ace-...@cse.wustl.edu
Hi Nikolai,

> I have a non-blocking TCP socket of type ACE_SOCK_Stream, and I
> was wondering if there is a cross platform way to check
> whether the 'recv' operation would block. I tried Google-ing
> and came across all kinds of controversy around this issue. On some
> platforms, It appears, these two are assigned the same numerical
> value, where as on others one or the other may not even
> exist or be assigned different values.

Right. Gotta love those standards ;-)

> Would it be correct to say that, for non-blocking sockets, both
> EAGAIN and EWOULDBLOCK represent the exact same error?

Yes.

> If so, is there any facility ACE has that performs this check?
> Something like "bool would_block(...)".

Yes, but it's even easier than that. ACE catches this condition deep
in the OS layer and changes EAGAIN to EWOULDBLOCK. So with ACE
sockets, just check for EWOULDBLOCK.

This comment from ACE_OS::send() explains:

// On UNIX, a non-blocking socket with no data to receive, this
// system call will return EWOULDBLOCK or EAGAIN, depending on the
// platform. UNIX 98 allows either errno, and they may be the same
// numeric value. So to make life easier for upper ACE layers as
// well as application programmers, always change EAGAIN to
// EWOULDBLOCK.

Best regards,

-Steve

--
Steve Huston, Riverace Corporation
Next public ACE training May 1-4, 2007!
See http://www.riverace.com/training.htm


Nickolai Dobrynin

unread,
Apr 4, 2007, 7:24:19 PM4/4/07
to Steve Huston, ace-...@cse.wustl.edu
Steve,

Thank you for your explanation.  What's hilarious is that I actually saw this very comment
you are referring to.  It's in OS_NS_sys_socket.inl.  But I completely misread what it said.
Somehow, I was under impression what the EAGAIN/EWOULDBLOCK dilemma is only
being handled for Unix's but intentionally left unhandled for Win32.  Since Windows XP
(and MSVC++ 7.1) is the environment I am currently in (sadly enough!),  this comment did
not seem very relevant.

But now that you say that EWOULDBLOCK should be used to check for potential blocking, that
pretty much answers the question.

Thanks to you and Doug Schmidt for answering!


Best,

Nickolai
0 new messages