The following issue has a resolution that has been APPLIED.
==
https://austingroupbugs.net/view.php?id=1448
==
Reported By:kre
Assigned To:
The following issue has been RESOLVED.
==
https://austingroupbugs.net/view.php?id=1448
==
Reported By:kre
Assigned To:
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=1448
==
Reported By:kre
Assigned To:
Date:Wed, 3 Feb 2021 09:59:20 -0800
From:Scott Lurndal
Message-ID: <20210203175920.ge19...@dragon.sl.home>
| When you combine "not block indefinitly" with O_NDELAY/O_NONBLOCK,
The standard doesn't (currently) say anything about expecting those
to be set on the
On Thu, Feb 04, 2021 at 12:08:17AM +0700, Robert Elz via austin-group-l at The
Open Group wrote:
> From:"Scott Lurndal via austin-group-l at The Open Group"
>
> | The application will not block _indefinitely_.
>
> That's not what the standard actually says, nor would it really
Date:Tue, 2 Feb 2021 15:24:33 -0800
From:"Scott Lurndal via austin-group-l at The Open Group"
Message-ID: <20210202232433.gc19...@dragon.sl.home>
| The application will not block _indefinitely_.
That's not what the standard actually says, nor would it really
On Tue, Feb 02, 2021 at 10:12:27PM +, Austin Group Bug Tracker via
austin-group-l at The Open Group wrote:
>
> what's important about poll() (and select()) is that after being told
> that an operation may be attempted, the application will not block when
> performing the relevant operation,
< said:
> Much the same applies to the write is OK bits in revents - but there
> there's another problem, the bit set indicates that some data can be
> written without blocking, but it does not promise how much. The
> APPLICATION USAGE section should probably be changed from None (line
> 46867)
The following issue has been SUBMITTED.
==
https://www.austingroupbugs.net/view.php?id=1448
==
Reported By:kre
Assigned To:
