Xref: utzoo comp.unix.microport:3092 comp.unix.xenix:5564
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!ukma!xanth!lll-winken!uunet!pcrat!rick
From: rick@pcrat.UUCP (Rick Richardson)
Newsgroups: comp.unix.microport,comp.unix.xenix,comp.unix.i386
Subject: Re: nap in Sys V (millisecond sleeps)
Summary: How to do it for SVR3.[012]
Keywords: XENIX SysV nap
Message-ID: <716@pcrat.UUCP>
Date: 6 Apr 89 01:14:10 GMT
References: <661@micropen> <743@omen.UUCP> <663@micropen> <1989Mar29.185842.14146@ateng.ateng.com> <608@pmafire.UUCP>
Reply-To: rick@pcrat.UUCP (Rick Richardson)
Organization: PC Research, Inc., Tinton Falls, NJ
Lines: 34

>:>>AT&T sucks for not having a sub-second clock interval.  Although XENIX nap()
>:>>is anemnic compared to BSD ftime().
>:>
>:>Which, of course, means that SysV missed the boat.  Except for SysV R3.2,
>:>which of course includes nap().

If you have SVR3.2 there is a nap() in /lib/libx.a.  But if you
are at SVR3.0 or .1 level, all is not lost.  In fact, any version
of UNIX that has the STREAMS modules configured can do a nap().

Here's how to do nap portably across all UNIXes with STREAMS:

	#include <stropts.h>
	#include <poll.h>
	nap(milliseconds)
	int	milliseconds;
	{
		struct pollfd	dummy[1];

		poll(dummy, 0L, milliseconds);
	}

By telling "poll(2)" to poll exactly zero stream fd's, it does
exactly that.  Since there is no way for any input to arrive
on zero fd's, poll just waits the timeout value.  The timeout
is spec'ed in milliseconds, but is probably subject to the
granularity of clock ticks on your computer (100/second on a 386).


-- 
Rick Richardson | JetRoff "di"-troff to LaserJet Postprocessor|uunet!pcrat!dry2
PC Research,Inc.| Mail: uunet!pcrat!jetroff; For anon uucp do:|for Dhrystone 2
uunet!pcrat!rick| uucp jetroff!~jetuucp/file_list ~nuucp/.    |submission forms.
jetroff Wk2200-0300,Sa,Su ACU {2400,PEP} 12013898963 "" \d\r\d ogin: jetuucp