From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 28-JUL-1994 10:54:36.53
To:	EVERHART
CC:	
Subj:	Re: Why does UCX perform IO every time you call select?

From: volz@process.com (Bernie Volz)
X-Newsgroups: comp.os.vms,vmsnet.networks.tcp-ip.ucx
Subject: Re: Why does UCX perform IO every time you call select?
Message-ID: <1994Jul28.095747.565@process.com>
Date: 28 Jul 94 09:57:47 -0400
Organization: Process Software Corporation
Lines: 26
To: Info-VAX@CRVAX.SRI.COM
X-Gateway-Source-Info: USENET

In article <3172v1$l09@zeus.london.micrognosis.com>, nreadwin@london.micrognosis.com (Neil Readwin) writes:
> Every time I call select() in a program that uses UCX the process is
> charged for another buffered IO operation. Can anyone explain why? For
> example, the following program notches up a nice steady 100 IO calls
> each second. This doesn't seem to do any harm, but is a little
> irritating. (Yes, I know using such a short timeout and polling for
> other events is brain-damaged, but I have a 150000 lines of code that
> does this and it is not feasible to fix that.) TIA, Neil.
> 

The "select" function is implemented as a QIO. Hence, a single QIO is
issued for each call to it. The QIO is given a list of all the channels
for read, write, and exception cases as well as the timeout interval.
This is an undocumented QIO (which we had to implement in TCPware's UCX
emulation support).

You might need to consider making use of ASTs and/or EFNs instead of
using the "polling" that you are now effectively doing. To do this,
you'd need to use the BGDRIVER QIOs directly.

Can't you increase the timeout time? Polling for events is kind of a
bad idea and VMS has such nice asynchronous I/O facilities that you
really ought to consider using them.

- Bernie Volz
  Process Software Corporation