Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: msleep
Message-ID: <361@PT.CS.CMU.EDU>
Date: Mon, 16-Nov-87 19:01:04 EST
Article-I.D.: PT.361
Posted: Mon Nov 16 19:01:04 1987
Date-Received: Wed, 18-Nov-87 07:19:49 EST
References: <332@PT.CS.CMU.EDU> <9310@mimsy.UUCP>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 60
Keywords: sleep millisecs
Xref: mnetor comp.lang.c:5446 comp.unix.questions:4936

In article <9310@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> 
> 0) Only certain 4BSD-based operating systems *have* setitimer.
>    (What this *really* means is that if you need a sleep that works
>    in milliseconds or microseconds or whatever, using a routine
>    like msleep is imperative.  Then the victim, er, user, of your
>    code need rewrite only msleep.)
> 
> 1) you can (and, I think, should) avoid the critical section by using
>    sigblock and sigsetmask (see man 2 sigblock).
> 
> 2) using setitimer is more expensive than calling select with three
>    `(fd_set *)0' arguments.  Select does have one problem: like
>    sigpause, it is interrupted by signals; unlike sigpause, it does
>    not take a signal mask, so it sometimes has unavoidable critical
>    sections.  (Yes, I want a sixth argument to select!)
> 
> 3) The actual granularity of interval timers (including select timers):
> 
> 	system				granularity
> 	4.[23]BSD Vax			10 ms
> 	Sun[23] running SunOS 3.x	20 ms
> -- 
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
> Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

   Sorry about #0, I didn't know SYSV doesn't provide itimers.


   #1 Sorry, I think critical section was a misnomer for what I meant.  The
problem that I was describing had to do with setting the itimer up
such that it interrupts only once (the second half of the structure set
to zeros).    If the ONLY timer interrupt was to come during the period
between the call to setitimer and  sigpause, my interrupt handle
would be called and then NOTHING would happen in sigpause to
make sigpause exit.  The only timer interrupt sounded would not have
caused sigpause to exit, since it sounded BEFORE entering into sigpause.
This is the rational behind using continuous interrupts (the second half
of the structure not set to zeros) when at first glance, someone might
think you could get away with just one.

BTW, yes I'm very familiar with the sigblock and sigsetmask functions,
they are not needed to implement this facility, setitimer suffices.


   Point two about setitimer being slower.  Does that really make
sense to complain about how long setitimer takes as compared to 
select!!!  If the interrupt timer's granularity is 10 millisecs, 
both select and msleep will usually time out at the same time (setitimer
has to be in the order of 100 micros per call).  Statistically though,
msleep should have a mean wait time that is a little longer than select.

  Also, don't you consider the use of select as a timer to be an
abuse of the function?  Then again, are you one that argues,
vfork is avid way to get shared mem in BSD. ;-)
-- 
That one looks Jewish -- And that one's a coon -- Who let all this riff raff
into the room -- There's one smoking a joint -- and Anoter with spots -- If
I had my way -- I'd have all of you shot ... Pink Floyd, "In the Flesh"
Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu