[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:	DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:	Welcome to the Digital UNIX Conference
Moderator:	SMURF::DENHAM

Created:	Thu Mar 16 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	10068
Total number of notes:	35879

8732.0. "_PC_ASYNC_IO?" by COMICS::EDWARDSN (Dulce et decorum est pro PDP program) Thu Feb 06 1997 04:43

A customer has got hold of a "posix 4, programming for the real world" book in which 
there is a parameter mentioned for pathconf () _PC_ASYNCH_IO, this would indicate
whether the device was capable of asynchronous I/O...
The question is, 

if this _PC_ASYNCH_IO exists, where is it, 
if it doesn't exist now, will it in future,
in it's absence what should they use.

i.e. is there a programmatical way of determining support for asynchronous I/O on a
port on an AXP 600 running DEC Unix.

Any answers please would be welcome.

Neil.

T.R	Title	User	Personal Name	Date	Lines
8732.1		DCETHD::BUTENHOF	Dave Butenhof, DECthreads	`Thu Feb 06 1997 07:59`	11
	First off, the name is _PC_ASYNC_IO, not _PC_ASYNCH_IO. I don't know whether you copied it wrong, or whether the book really does say "ASYNCH". If that's what it says, it may well be because the book is obsolete. That is, while it has a lot of good general information on POSIX and realtime programming, it talks about a DRAFT version of the POSIX realtime standard, not the final standard. Secondly, Digital UNIX doesn't appear to have a definition for _PC_ASYNC_IO, and that's a bug. You should QAR it (as a "standards conformance" bug). /dave
8732.2	This should arrive in a future release	UNIFIX::HARRIS	Juggling has its ups and downs	`Thu Feb 06 1997 10:25`	7
	> Secondly, Digital UNIX doesn't appear to have a definition for > _PC_ASYNC_IO, and that's a bug. You should QAR it (as a "standards > conformance" bug). This and other related stuff is part of the UNIX98 branding work. Bob Harris
8732.3	Excellent answers.	COMICS::EDWARDSN	Dulce et decorum est pro PDP program	`Fri Feb 07 1997 09:36`	6
	O.k. I misheard it on the phone and typed it in wrong. Sorry. I'll pay more attention next time. So, what should be used in the meantime until UNIX98 comes along? Neil.
8732.4		DCEIDL::BUTENHOF	Dave Butenhof, DECthreads	`Mon Feb 10 1997 08:40`	32
	Regardless of UNIX98, the omission of this symbol from <unistd.h> on Digital UNIX 4.0 and later is a STANDARDS CONFORMANCE BUG. This symbol is REQUIRED by POSIX 1003.1b-1993. Digital UNIX 4.0 claims conformance to that standard and therefore must supply that symbol. It does not. The fact that POSIX doesn't do validation or testing of implementations claiming conformance means that it's easy to overlook (or ignore) details like this, but it's still a bug. The reason you may see "UNIX98" tossed around as the answer is that, unlike POSIX, The Open Group (X/Open plus OSF -- the owners of the UNIX trademark and developers of the "Single UNIX Specification" called "UNIX95" and the UNIX98 followon) provides a test suite to verify conformance. If you don't pass, you don't get to use the UNIX name or claim conformance. (Clearly a serious problem when we use UNIX in the product name!) But the fact remains that this is a bug NOW. It means, very simply (although in a perhaps trivial sense) that Digital UNIX 4.0 does NOT conform to the POSIX 1003.1b-1993 standard. It would "undoubtedly"() be fairly easy to fix this problem for all versions of Digital UNIX 4.0, so there's no justification for ignoring the problem until UNIX98 conformance becomes an issue next year. Why wait? So enter a QAR. Or a CLD, or whatever seems proper given the situation and customer perception of the severity of this problem. Of course, you can easily work around the problem, too. /dave () Note that I say "undoubtedly" with only guesses about what's involved. The fix requires adding the symbol to <unistd.h> and proper support for that symbol in pathconf() -- which may be trivial or involve substantial new I/O subsystem support. (But probably not, since libaio does async I/O using threads for any filesystem that doesn't have kernel/driver async I/O support.)