[parisc-linux] Re: EWOULDBLOCK vs. EAGAIN

[parisc-linux] Re: EWOULDBLOCK vs. EAGAIN

[John Marvin]

OK, I should have checked the archives first. It looks like this issue
has already come up. In that case we fixed the app. But I'm not comfortable
with the fact that we are different from every other architecture here.

Yes, to be completely portable across other Unix flavors, you should
check for both EAGAIN and EWOULDBLOCK. But it would appear that
Gnu C library documentation says they should be the same, and they
ARE the same on all other Linux architectures. So, in my opinion,
we are broken, not the apps.

John

P.S. I know most of you don't care, but the broken app in this case is
telnetd. It drops connections if you blast too much to stdout.

Re: [parisc-linux] Re: EWOULDBLOCK vs. EAGAIN

[Randolph Chung]

In reference to a message from John Marvin, dated Oct 22:
> OK, I should have checked the archives first. It looks like this issue
> has already come up. In that case we fixed the app. But I'm not comfortable
> with the fact that we are different from every other architecture here.

John, I was refering to the suggestion Carlos made that we can "fix up"
the return value in the syscall return path in glibc. Looks like there
is already precedence for this sort of thing, and that way we retain
binary compatibility with both hppa-linux and potentially with hpux.

> P.S. I know most of you don't care, but the broken app in this case is
> telnetd. It drops connections if you blast too much to stdout.

heh, now that you mention it, this explains some things...:-)

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] Re: EWOULDBLOCK vs. EAGAIN

[John David Anglin]

> Yes, to be completely portable across other Unix flavors, you should
> check for both EAGAIN and EWOULDBLOCK. But it would appear that
> Gnu C library documentation says they should be the same, and they
> ARE the same on all other Linux architectures. So, in my opinion,
> we are broken, not the apps.

I just looked at expect.  It uses 

#ifdef EAGAIN
        case EAGAIN: return "resource temporarily unavailable";
#endif
...
#if defined(EDEADLK) && (!defined(EWOULDBLOCK) || (EDEADLK != EWOULDBLOCK))
        case EDEADLK: return "resource deadlock avoided";
#endif
#if defined(EDEADLOCK) && (!defined(EDEADLK) || (EDEADLOCK != EDEADLK))
	case EDEADLOCK: return "resource deadlock avoided";
#endif
...
#if defined(EWOULDBLOCK) && (!defined(EAGAIN) || (EWOULDBLOCK != EAGAIN))
        case EWOULDBLOCK: return "operation would block";
#endif

This seems portable to me.

I agree that the definition of EWOULDBLOCK should be the same as on
other Linux architectures.  However, I think that apps should work
irrespective of whether they are the same or not.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] Re: EWOULDBLOCK vs. EAGAIN

[GOTO Masanori]

At Tue, 22 Oct 2002 08:54:35 -0700,
Randolph Chung wrote:
> In reference to a message from John Marvin, dated Oct 22:
> > OK, I should have checked the archives first. It looks like this issue
> > has already come up. In that case we fixed the app. But I'm not comfortable
> > with the fact that we are different from every other architecture here.
> 
> John, I was refering to the suggestion Carlos made that we can "fix up"
> the return value in the syscall return path in glibc. Looks like there
> is already precedence for this sort of thing, and that way we retain
> binary compatibility with both hppa-linux and potentially with hpux.

I wonder it's not important changing EWOULDBLOCK -> EAGAIN to keep
hpux (or old sysv) compatibility...  Now SusV3 says EWOULDBLOCK may be
same as EAGAIN, a conforming implementation may assign the same
values. Are there any reasons to retain this?

I don't know whether hpux binary can run on hppa-linux or not,
but if EWOULDBLOCK is not same as EAGAIN, serious problem is occured?
I think keeping compatibity to other linux is more important than
hpux binaries... (Well, I'm not hppa-linux user, so please tell me
these status/circumstance).

> > P.S. I know most of you don't care, but the broken app in this case is
> > telnetd. It drops connections if you blast too much to stdout.
> 
> heh, now that you mention it, this explains some things...:-)

So, telnetd should be fixed...?

Regards,
-- gotom