HDTenEightyP/NetNews huggingface dataset:
From: maer@nmr.lpc.ethz.ch (Matthias Ernst)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problems running xntp v3 on SGI Indigo
Date: 26 Aug 92 06:41:19 GMT
Distribution: inet
Organization: The Internet

-> In article <1992Aug25.185749.29102@jhunix.hcf.jhu.edu> andy@jhunix.hcf.jhu.edu (Andy Poling) writes:
-> >From ntp_unixclock.c in my xntpdv2 (xntpv3 is still on my todo list) port
-> >which ticks nicely on a 4D/300:
-> >
-> > [code deleted]
-> 
-> Thanks; I changed tick and tickadj to your values, but xntpd is still not
-> working quite right.  It seems to feel that it needs to do a step adjustment
-> but can't because watchdog_timer is less than CLOCK_MINSTEP.  When it
-> finally does get to do the step adjustment, it zeros watchdog_timer and
-> starts over again.  It then decided it needs to do a step adjustment, etc.
-> ad nauseum.
-> 
-> 
-> Mike
-> 
-> 
-> Here's an example from the syslog file:
-> 
-> Aug 25 16:02:58 indigo xntpd[500]: xntpd version 3.1
-> Aug 25 16:03:00 indigo xntpd[500]: system event 1 status c010
-> Aug 25 16:03:34 indigo xntpd[500]: peer 128.200.34.4 event 84 status 9014
-> Aug 25 16:03:34 indigo xntpd[500]: system event 4 status c621
-> Aug 25 16:03:34 indigo xntpd[500]: peer 128.200.16.3 event 84 status 9014
-> Aug 25 16:08:53 indigo xntpd[500]: system event 3 status 634
-> Aug 25 16:09:57 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.144103289)
-> Aug 25 16:11:01 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.156219959)
[syslog deleted]
 
I just saw your second posting and checked your machine. It seems to synchronize
fine and run stable. Did you wait long enough for xntpd to adjust the drift value ?

|curie> date
Wed Aug 26 08:36:06 MET DST 1992
|curie> ntpq3 -p halide.acs.uci.edu
     remote           refid      st when poll reach  delay  offset   disp
=========================================================================
*einstein.oac.uc fuzz.sdsc.edu    2  230  256  377     3.4    2.37   16.0
+draco.acs.uci.e wwvb.isi.edu     2   67  256  377     3.3    6.79   17.4

Matthias

+-----------------------------------------------------------------------------+
| Matthias Ernst                          Domain: maer@nmr.lpc.ethz.ch        |
| Institut fuer physikalische Chemie      Bitnet: maer@czheth5a.bitnet        |
| Eidgenoessische Technische Hochschule   UUCP:   ...!mcsun!chx400!ethz!maer  |
| ETH-Zentrum                             Phone:  +41/1/256-4374              |
| CH-8092 Zuerich                         Fax:    +41/1/252-3402              |
+-----------------------------------------------------------------------------+
From: franco@bbn.com (Frank A. Lonigro)
Newsgroups: comp.protocols.time.ntp
Subject: computer clock drift
Date: 28 Aug 1992 23:24:05 GMT
Organization: Bolt Beranek and Newman, Cambridge MA
Distribution: world
NNTP-Posting-Host: countach.bbn.com
Originator: franco@countach.bbn.com

I'm interrested in finding out just how good/bad the system clocks in
SUN, DEC and HP's really are.  I'm trying to find out the most optimal
frequency, with the least amount of bombardment to my stratum 2 servers,
with which to run ntpdate out of crontab.

On average, do the system clocks, in the above mentioned hardware, drift
more than a half a second an hour?  More than a half a second every 2 hours?
Every 3 hours?  So on?  Just how bad are these clock in these computers?

Thanks,
-franco
-- 

Frank A. Lonigro	     (franco@bbn.com, ...!harvard!bbn!franco)
Bolt Beranek and Newman, Inc., 10 Moulton St., Cambridge, Mass. 02238
"e, s, s, s, n, e, e, nw, get chest, se, n, d" - Sound familiar??????
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: Problems running xntp v3 on SGI Indigo
Newsgroups: comp.protocols.time.ntp
Organization: University of California, Irvine
Keywords: tick, tickadj, SGI
Date: 26 Aug 92 05:32:19 GMT

In article <1992Aug25.185749.29102@jhunix.hcf.jhu.edu> andy@jhunix.hcf.jhu.edu (Andy Poling) writes:
>From ntp_unixclock.c in my xntpdv2 (xntpv3 is still on my todo list) port
>which ticks nicely on a 4D/300:
>
> [code deleted]

Thanks; I changed tick and tickadj to your values, but xntpd is still not
working quite right.  It seems to feel that it needs to do a step adjustment
but can't because watchdog_timer is less than CLOCK_MINSTEP.  When it
finally does get to do the step adjustment, it zeros watchdog_timer and
starts over again.  It then decided it needs to do a step adjustment, etc.
ad nauseum.


Mike


Here's an example from the syslog file:

Aug 25 16:02:58 indigo xntpd[500]: xntpd version 3.1
Aug 25 16:03:00 indigo xntpd[500]: system event 1 status c010
Aug 25 16:03:34 indigo xntpd[500]: peer 128.200.34.4 event 84 status 9014
Aug 25 16:03:34 indigo xntpd[500]: system event 4 status c621
Aug 25 16:03:34 indigo xntpd[500]: peer 128.200.16.3 event 84 status 9014
Aug 25 16:08:53 indigo xntpd[500]: system event 3 status 634
Aug 25 16:09:57 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.144103289)
Aug 25 16:11:01 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.156219959)
Aug 25 16:12:05 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.191688538)
Aug 25 16:13:09 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.191688538)
Aug 25 16:14:14 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.215938807)
Aug 25 16:15:18 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.252199888)
Aug 25 16:16:22 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.288886309)
Aug 25 16:17:26 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.301805019)
Aug 25 16:18:30 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.327338219)
Aug 25 16:19:34 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.352847338)
Aug 25 16:20:38 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.391964436)
Aug 25 16:21:42 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.404758930)
Aug 25 16:22:46 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.430722237)
Aug 25 16:23:50 indigo xntpd[500]: adjust: STEP dropped (128.200.34.4 offset -0.457057238)
Aug 25 16:24:54 indigo xntpd[500]: adjust: STEP 128.200.34.4 offset -0.497189045
Aug 25 16:24:53 indigo xntpd[500]: system event 5 status c043
Aug 25 16:25:57 indigo xntpd[500]: peer 128.200.16.3 event 84 status 9024
Aug 25 16:25:57 indigo xntpd[500]: system event 4 status c655
Aug 25 16:25:57 indigo xntpd[500]: peer 128.200.34.4 event 84 status 9024
From: andy@jhunix.hcf.jhu.edu (Andy Poling)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Problems running xntp v3 on SGI Indigo
Keywords: tick, tickadj, SGI
Date: 25 Aug 92 18:57:49 GMT
Followup-To: comp.protocols.time.ntp
Organization: HAC - Johns Hopkins University, Baltimore

In article <2A9A652F.8451@orion.oac.uci.edu> iglesias@draco.acs.uci.edu (Mike Iglesias) writes:
>I'm trying to run the latest release of xntp v3 on an SGI Indigo running
>v4.0.1 of the OS.  xntpd is having trouble keeping the clock in sync,
>generating lots of STEP adjustments in the syslog file.  Since the
>SGI build uses -DNOKMEM, it's using the built-in values for tick and
>tickadj.  I'm assuming these are wrong for the SGI Indigo and that
>is what is causing the problem.  Does anyone have a good idea for
>tick and tickadj values for Indigos?

From ntp_unixclock.c in my xntpdv2 (xntpv3 is still on my todo list) port
which ticks nicely on a 4D/300:

void
clock_parms(tickadj, tick)
	u_long *tickadj;
	u_long *tick;
{
#ifdef sgi
        /*
	 * no use screwing around in memory when you've got system calls that
	 * can tell you all you need to know - ASP
	 */
#include <unistd.h>
	/*
	 * all IRIX clocks will run at 100 HZ if fastclock is disabled.
	 * Therefore 100 is a good default value if the sysconf call fails -
	 * ASP
	 */
   	if ((*tick = sysconf(_SC_CLK_TCK)) <= 0)
		*tick = (unsigned long)100L;
        /*
	 * It's difficult to figure out which IRIX kernel value corresponds to
	 * BSD's tickadj, so we fake it... - ASP
	 */
	*tickadj = (unsigned long)1L;
#ifdef DEBUG
	if (debug)
		printf("tick = %d, tickadj = %d\n", *tick, *tickadj);
#endif
return;
#endif
.
.
.

-Andy

Andy Poling                              Internet: andy@jhunix.hcf.jhu.edu
UNIX Systems Programmer                  Bitnet: ANDY@JHUNIX
Homewood Academic Computing              Voice: (410)516-8096    
Johns Hopkins University                 UUCP: uunet!mimsy!aplcen!jhunix!andy

	
Newsgroups: comp.protocols.time.ntp
From: kwolters@fred.wellesley.edu (Keith Wolters)
Subject: insane peers
Organization: Wellesley College
X-Newsreader: Tin 1.1 PL5
Date: Wed, 26 Aug 1992 14:34:59 GMT

Hi.  I just installed xntp on a number of machines here so I still
don't completly understand this stuff.  On a MicroVAX II running
Ultrix 4.0 I noticed that if I use the lassociations command within
ntpq, all my peers are listed as being insane.  Can anyone tell what
that indicates.  Thanks.

Keith
--
Keith Wolters
System Manager
Wellesley College
Newsgroups: comp.protocols.time.ntp
From: mrl@uai.com (Mark R. Ludwig)
Subject: Finding Network Time servers on the Internet
Followup-To: poster
Organization: Universal Analytics, Inc., Torrance (LA), CA
Date: 1 Sep 92 07:39:11

We're a site recently connected to the Internet.  I'd appreciate
information about how to start synchronizing our local network with
one or more servers "out there."

Thanks in advance for any pointers.  

Please reply directly; I'll summarize.$$
-- 
INET: mrl@uai.com      BANG: uunet!uaisun4!mrl      ICBM: USA; Lower Left Coast
  "You can get a crowd to clap at a phone number, if the inflection is right."
   -- Dave Ross
From: jonkar@rsv.svskt.se (Jonas Karlsson)
Newsgroups: comp.protocols.time.ntp
Subject: Have xntp v3 been ported to hp-ux?
Date: 26 Aug 92 08:03:06 GMT
Organization: Swedish Tax Administration

Have xntp v3 been ported to hp-ux and where can i get it?

/jk
-- 
Jonas Karlsson |                                   | Tel:   +46 8 7648444
RSV   S-171 94 |        This space for rent!       | Fax:   +46 8 294975
Solna, Sweden  |                                   | Email: jonkar@rsv.svskt.se
From: iglesias@draco.acs.uci.edu (Mike Iglesias)
Subject: Re: tickadj value for Sun 690mp??
Newsgroups: comp.protocols.time.ntp
Organization: University of California, Irvine
Date: 2 Sep 92 05:25:52 GMT

In article <18106lINNodk@overload.lbl.gov> tierney@portnoy.lbl.gov.itg writes:
>Does anyone know the tickadj value for a 690mp.  A value of 9999 seems to
>work well on our other Suns, but not the 690 (I've also tried 9998, and
>that doesnt seem to be any better)

Sun 690mp systems have got to have the worst clocks I've seen here.  When I
ran ntp on our 690mp, ntp said the drift was about 20 sec/day slow.  xntp
v3 says the drift is around 53-57 (ppm?).  From other messages I've
seen here, others are having the same problem.


Mike
From: pdh@netcom.com (Phil Howard )
Newsgroups: comp.std.unix
Subject: asyncronous I/O notification in POSIX: a question
Date: 27 Aug 1992 16:55:33 -0700
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: pdh@netcom.com (Phil Howard )

I read in "POSIX PROGRAMMER'S GUIDE - Writing Portable UNIX Programs", by
Donald Lewine (O'Reilly & Associates, publisher)...

...that POSIX has a macro flag called O_NONBLOCK, which can be used in
open() and in fcntl() to effect asyncronous I/O.  I also read that the
read() and write() functions will return an error with the EAGAIN value
in "errno" ifn the attempted I/O would block the process to complete that
function call.

What I cannot find or cannot figure out is how the process that has
received the EAGAIN code from one of these functions is going to be
able to be notified of the fact that I/O is now completeable when that
condition exists, and how it can find out which file descriptor(s) has
the I/O ready (of probably 2 or more in cases where the benefit of the
asyncronous I/O is helpful).

The mechanism I use in BSD is the select() function.

I don't have access to a POSIX conformant system at the present time,
but I would like to design new programs I write so that are "POSIX ready"
as much as I can do it, so that the effort to port them to POSIX is
trivial (hopefully).

Can anyone fill me in on how this is done?  If you think it is best to
send me e-mail directly, send it to: pdh@netcom.com.  Thanks.
-- 
/***********************************************************************\
| Phil Howard  ---  KA9WGN  ---  pdh@netcom.com   |   "The problem with |
| depending on government is that you cannot depend on it" - Tony Brown |
\***********************************************************************/


Volume-Number: Volume 29, Number 14
From: pdh@netcom.com (Phil Howard )
Newsgroups: comp.std.unix
Subject: progress of UNIX standardization: a question
Date: 28 Aug 1992 13:19:47 -0700
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: pdh@netcom.com (Phil Howard )

For my next question, I would like to find out what the progress of
standardizing a programming interface is in UNIX.  Is it already
"carved in stone" now, or are things still being added by whoever
does these things?  If yes, is there any means for providing input?
-- 
Phil Howard  ---  KA9WGN  ---  pdh@netcom.com


Volume-Number: Volume 29, Number 16
From: guy@auspex.com (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: Unix Wars Over (Query)
Date: 31 Aug 1992 02:33:48 -0700
Organization: Auspex Systems, Santa Clara
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: guy@auspex.com (Guy Harris)

>Thus the same programming
>environment will exist on either system regardless of whether you developed to
>SVID or AES.

Well, the SVID and AES environments will exist on both systems; however,
an application may well want to use interfaces *not* in the SVID or AES.

For example, SVR4's run-time dynamic linking interface ("dlopen()",
"dlsym()", etc.) wasn't in the SVID, last time I looked (and yes, I
*did* look in the Third Edition, the SVR4 SVID).  Dunno if OSF/1's
run-time dynamic linking interface is there or not (I believe it has
one).

(NOTE: "run-time dynamic linking interface", with the emphasis on
"run-time".  This doesn't say anything about SVR4's or OSF/1's shared
library mechanisms, just about SVR4's and OSF/1's mechanisms to allow an
application to make calls to attach a lump of code, by file name, at run
time, with the file name possibly generated at run time, and to find
routines in that attached lump of code by name, with the routine name
possibly generated at run time.)


Volume-Number: Volume 29, Number 18
From: sp@osf.org (Simon Patience)
Newsgroups: comp.std.unix
Subject: Re: Unix Wars Over (Query)
Date: 28 Aug 1992 13:31:05 -0700
Organization: Open Software Foundation
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: sp@osf.org (Simon Patience)

In article <17jq00INN7ei@ftp.UU.NET>, jklobas@ecel.uwa.edu.au (Jane Klobas - mgmt_staff) writes:
> Submitted-by: jklobas@ecel.uwa.edu.au (Jane Klobas - mgmt_staff)
> 
> An industry colleague recalls seeing a press release that stated that the
> "competing UNIX standards have merged".  I recall a notice that suggested
> that SVID is supported by both OSF and UI.  Of course, neither of us can
> locate the articles in which we think these statements occurred :-)
> Can anyone shed any light on this, either by confirming or refuting these
> statements, or by identifying the press release/article in which they
> appeared?

I will not confirm/deny/comment on anything to do with "Unix wars" but what
may help you are the facts that a) OSF/1 1.0 supported SVID 2 and OSF/1 1.1
supports SVID 3 and b) USL has just announced that System V will support OSFs
AES (Application Environement Specification). Thus the same programming
environment will exist on either system regardless of whether you developed to
SVID or AES.  OSF and UI/USL have always worked together anyway to ensure
that these two specifications are not contradictory, this is just another
step in the co-operation.

Simon.
-- 
  Simon Patience
  Open Software Foundation			Phone: +33-76-63-48-72
  Research Institute				FAX:   +33-76-51-05-32
  2 Avenue De Vignate				Email: sp@gr.osf.org
  38610 Gieres, France				       uunet!gr.osf.org!sp


Volume-Number: Volume 29, Number 17
From: jklobas@ecel.uwa.edu.au (Jane Klobas - mgmt_staff)
Newsgroups: comp.std.unix
Subject: Unix Wars Over (Query)
Date: 27 Aug 1992 16:54:40 -0700
Organization: UUNET Communications
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: jklobas@ecel.uwa.edu.au (Jane Klobas - mgmt_staff)

An industry colleague recalls seeing a press release that stated that the
"competing UNIX standards have merged".  I recall a notice that suggested
that SVID is supported by both OSF and UI.  Of course, neither of us can
locate the articles in which we think these statements occurred :-)
Can anyone shed any light on this, either by confirming or refuting these
statements, or by identifying the press release/article in which they
appeared?

-
Jane Klobas                                     Phone:  +61 9 380 3567
Lecturer, Department of Management              Fax:    +61 9 380 1004
University of Western Australia                 email:  jklobas@ecel.uwa.oz.au
Nedlands  WA  6009  Australia


Volume-Number: Volume 29, Number 13
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: POSIX update
Date: 31 Aug 1992 12:50:51 -0700
Organization: U.S. Army Ballistic Research Lab, APG MD.
NNTP-Posting-Host: ftp.uu.net
Keywords: posix, unicode, iso10646
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <17e68qINNj6j@ftp.UU.NET> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>The C standard explicitly allows a ``byte'' to be more than eight
>bits, and 16-bit Unicode bytes is a very reasonable decision in some
>contexts. But it might be that POSIX has additional requirements that
>make it impossible for such a system to conform --- and if the POSIX
>committee had been aware of Unicode, it would have made sense to avoid
>such a conflict.

IEEE Std 1003.1 also predated ISO 10646.

Anyway, during X3J11/WG14 debates over the best way to support large
character sets, most vendors were not willing to make "char" anything
other than an 8-bit datum, due to existing code such as network
interfaces where the 8-bit "char" assumption was pervasive.  Of course
one could argue that that was poorly designed code in the first place,
but it was deemed to be economically important to continue to assign
exactly 8 bits for "char" in many environments.  If it had not been
for that consideration, both the Japanese "long char" and my own
"short char" alternatives would probably have received more committee
support.

(I have seen nothing in the intervening years to make me think that
the so-called "short char" proposal is not technically the best
alternative.)

>It is true that the first DIS 10646 (which had nothing to do with
>Unicode) could be fitted into the multibyte framework, even though
>the intention seems to have been ...

Sorry, that's what I meant.  For historical reasons some of us lump
all the variations on IBM's Unicode AND (D)IS 10646 into the same
bucket.  However, it's IS 10646 that matters for this forum.


Volume-Number: Volume 29, Number 19
From: peter@ferranti.com (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: ISO 10646 files
Date: 23 Aug 1992 14:17:26 -0700
Organization: Xenix Support, FICC
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: peter@ferranti.com (Peter da Silva)

In article <16rpgaINNol0@ftp.UU.NET> david@mks.com (David Rowley) writes:
> Note that UTF and 8-bit Latin 1 (ISO 8859-1) are identical for
> characters 0x00 to 0x9f.  Codepoints above 0x9f are used to
> introduce the multibyte sequences.

That seems strange. 0x80 through 0x9f are all controls, and all the
national characters in Latin-1 are in 0xA0 to 0xFF. Why would they allow
Latin-1 control codes (CSI, etc) and blow off all the graphics? Are you
sure they didn't overload the high control range (0x80 to 0x9f)? That
would seem a much more useful encoding.
-- 
Peter da Silva
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180


Volume-Number: Volume 29, Number 8
From: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)
Newsgroups: comp.std.unix
Subject: Re: ISO 10646 files
Followup-To: alt.religion.computers
Date: 23 Aug 1992 14:18:57 -0700
Organization: IR
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)

Markus Kuhn writes:
>   - In this way, every UNIX tool (cc, cat, ...) can easily determine,
>     how the file has to be interpreted,

Interfaces should be _small_. By definition a small interface has simple
semantics. Simple semantics leave no room for bugs. A small interface is
programmer-friendly.

Version 7 UNIX had small interfaces. The kernel's system call interface
was small: just a few dozen calls with semantics defined in a few pages.
Each utility's external interface was small: there were almost no
conventions weighing things down. Even the internal interfaces were
small: most tools used mere pages of code.

File types infect practically every program on the system. Witness VMS.
Every program's semantics has to include its treatment of file types.
This means that the total interface size of the system becomes much,
much, much larger.

Need I say more?

Followups to alt.religion.computers.

---Dan

[ I did set Followups to alt.religion.computers, but only because Dan
  wanted it. -- mod ]

Volume-Number: Volume 29, Number 9
From: karish@pangea.stanford.edu (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: asyncronous I/O notification in POSIX: a question
Date: 27 Aug 1992 18:05:06 -0700
Organization: Mindcraft, Inc.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: karish@pangea.stanford.edu (Chuck Karish)

In article <17jq1lINN7gc@ftp.UU.NET> pdh@netcom.com (Phil Howard ) writes:

>What I cannot find or cannot figure out is how the process that has
>received the EAGAIN code from [a non-blocking read() or write()] is
>going to be
>able to be notified of the fact that I/O is now completeable when that
>condition exists, and how it can find out which file descriptor(s) has
>the I/O ready (of probably 2 or more in cases where the benefit of the
>asyncronous I/O is helpful).
>
>The mechanism I use in BSD is the select() function.

The description of [EAGAIN] in POSIX.1 is:

    [EAGAIN] Resource temporarily unavailable
             This is a temporaty condition, and later calls to
             the same routine may complete normally.

The portable way to find out whether the resource has become
available (modem connection completed, data ready, memory available,
etc.) is to wait a while, then try again.
--

    Chuck Karish          karish@mindcraft.com
    (415) 323-9000 x117   karish@forel.stanford.edu


Volume-Number: Volume 29, Number 15