From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 28-JAN-1994 09:26:57.38
To:	EVERHART
CC:	
Subj:	Re: Operation of select on std i/o?

X-Newsgroups: comp.os.vms
Subject: Re: Operation of select on std i/o?
Message-Id: <2i3rjc$36t@skates.gsfc.nasa.gov>
From: alex@tpocc.gsfc.nasa.gov (Alex Measday)
Date: 25 Jan 1994 19:23:24 GMT
Organization: Integral Systems, Inc.
Nntp-Posting-Host: tpocc.gsfc.nasa.gov
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Lines: 73
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET


>	In the VMS port 'select' works fine with the socket inputs but doesn't
>	seem to recognise that there is data on stdin. Any suggestions?

In my programs that need to do the same thing, I put a 0.25-second timeout
in the SELECT(2) call and poll a channel assigned to standard input.  If
input is detected on standard input, I then go on and read it using GETS(3)
or FGETS(3), I forget which.  I suspect that input is detected when you
type the first character on the input line, so the FGETS() will block your
program until you hit a carriage return.  This wasn't a problem for my
applications, so I didn't investigate it much at all.  My polling function,
TTY_POLL(), "senses" the type-ahead count of the channel; is there another
way of detecting input at the complete line level (i.e., when the carriage
return is entered)?


>	I couldn't find the VMS implementations of the FD_SET etc macros so I
>	copied the OSF definitions. Is this the problem? (But it does work
>	with the sockets.......)
>

The definitions of these macros that we used were based on an old set of
SunOS definitions (3.4, I think); the OSF/1 definitions are probably
similar.  We did upgrade the definitions eventually.  The Sun definitions
used "/"s and "%"s to access individual bits in the bit masks, which
produced really bad VAX machine code (extended precision arithmetic).
Taking advantage of the 32-bit word size, I replaced the arithmetic
calculations by bit shifts, "<<"s and ">>"s, and defined FD_ZERO as
a _MOVC5.

A couple of items of information that might be of use to you:

(1) The UCX documentation makes it sound as if SELECT() is limited to
    32-bit wide bit masks, covering file descriptors 0 to 31.  A kind
    Digital employee (in this very news group) checked the actual code
    and found that it works for masks of any width.  We redefined
    FD_SETSIZE from 32 to 128 (some of our server processes had more
    than 32 simultaneous connections or files open).

(2) The UCX implementation of SELECT() apparently used the same FD_xxx
    definitions as SunOS - it does the same extended precision arithmetic
    to access individual bits in the bit masks.  Consequently, the UCX
    SELECT() can be very slow depending on the width of the bit masks.
    If performance is a problem for you, it pays to pass in to SELECT()
    the highest-numbered socket descriptor plus one as the width of the
    bit mask.


>	Is there a problem using read and write system calls with this version
>	of UCX? ...

We had no problems with them.


In article <19584330@MVB.SAIC.COM> Jerry Leichter <leichter@lrw.com> writes:
>...
>in the VMS I/O system - the preferred approach is to do asynchronous I/O,
>which unlike the case in Unix (a) is supported for all I/O devices and (b) is
>very efficient - and the simulation in this case is particularly complex.
>...

Asynchronous I/O is a feature sorely lacking in most versions of UNIX,
but one nice advantage of the UNIX SELECT() is that it provides a single
mechanism for polling (or waiting on) devices of any type.  Under VMS,
each type of device has its own separate QIO conventions.  For example,
polling a channel assigned to standard input requires a different set
of QIO flags/modifiers than those required when polling a network socket
connection, at least in my experience.


                                Alex Measday
                                Integral Systems, Inc.
                                alex@tpocc.gsfc.nasa.gov