All
A number of items for todays teleconference
regards
Andrew
---------------
XSH ERN 127 getnameinfo
http://www.opengroup.org/austin/mailarchives/ag/msg09425.html
Issues with Austin 280r1 raised on the reflector:
SD5 XBD ERN 4
-------------
In Austin/280r1 (editors notes arising from SD/5) there is the
following for XBD ERN 4:
|On XSH page 350 fdopen
|
|Delete 11491 in the ERRORS section:
|
|11491 [EMFILE] {STREAM_MAX} streams are currently open in the calling
process.
|
|STREAM_MAX is required to be the same value as FOPEN_MAX
|and so we do not need the separate error case.
|
|Errors that reference FOPEN_MAX or STREAM_MAX should coalesced
|to be
|
| [EMFILE] {FOPEN_MAX} (and {STREAM_MAX} if defined) streams ...
I don't think that's right.
Although the constant STREAM_MAX in limits.h must, if defined, have
the same value as FOPEN_MAX (the constant in stdio.h), the notation
{STREAM_MAX} in the EMFILE text refers to the limit value obtained
from sysconf(_SC_STREAM_MAX), which can be different from FOPEN_MAX.
It would be less confusing if the braces were omitted from {FOPEN_MAX}.
(I think the braces should really only be used when referring to a
limit value obtainable from sysconf() or pathconf(), and not when
referring to constants defined in headers. Unfortunately there are
several places where the braces are also used for constants.)
Also, since the actual {STREAM_MAX} limit can be queried at runtime,
I think the EMFILE errors for exceeding {STREAM_MAX} should probably
be "shall fail" errors, not "may fail" errors. (The FOPEN_MAX EMFILE
errors need to stay as "may fail".)
XSH ERN 120
-----------
In Austin/280r1 (editors notes arising from SD/5) there is the
following for XSH ERN 120:
|XSH sched_yield
|
|Add to APPLICATION USAGE
|Since there may not be more than one thread runnable in a process
|a call to sched_yield() might not relinquish the processor at all.
|In a single threaded application this will always be case.
The last sentence of this doesn't seem right. The shading on
sched_yield() is PS|THR, not just THR, implying that it is
supposed to have an effect on (realtime) process scheduling as
well as thread scheduling. I.e. if a single threaded application
calls sched_yield() should it not relinquish the processor for use
by other processes?
--
Andrew Josey The Open Group
Austin Group Chair Thames Tower, 37-45 Station Road,
Email: yyyyyyy@xxxxxxxxxxxxx Reading,Berks.RG1 1LX,England
Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110
|