Subject: Re: usleep and signals
To: None <rickb@iaw.on.ca>
From: maximum entropy <entropy@zippy.bernstein.com>
List: current-users
Date: 08/18/1997 12:07:23
>From: Rick Byers <rickb@iaw.on.ca>
>
>Granularity of 1 second is fine.  But after looking at the source (I
>didn't feel like thinking at it at 3:00am last night <grin>), I see a
>problem.  Sleep will still respond to my timer even though I have set it
>to ignore, and since my timer fires once a second, this poses the same
>problem as just sleeping for the desired time.  The time difference
>returned by sleep when it's interrupted is only accurate to the second.
>The obvious work around is to simply dissable my timer, and re-enable it
>afterwards.  I don't think I have to worry about changing the signal
>handler because sleep does that for me.  Does this sound ok?

Yes, calling alarm(0) before the sleep and then resetting the alarm
afterwards should do what you want.

>Your patch for usleep worked fine.  The nanosleep man page even says it
>will return an error if tv_nsec is greater than 1 billion (1 second).  The
>usleep man page should be changed to reflect the fact that usleep will
>cancel upon receipt of a signal (and will set errno).  Personally, I don't
>like this.  It should either ignore signals, or return the unslept time.
>We could easily put the nanosleep in a loop and keep sleeping for the
>unslept time to ensure usleep sleeps as long as it should.  Or is usleep
>expected to return when a signal is delivered?

Yes, usleep() is expected to be interrupted by signals.  The fact that
it doesn't return the unslept time is an annoyance, but probably needs
to stay that way or compatibility with hundreds of software packages
could potentially be lost.  You'd be surprised how many packages
declare "void usleep()" somewhere in the code.

I sent in a pr with my patch this morning.  The pr mentions that you
found the bug.

I agree with you that the man page for usleep could be more explicit
about how signals are handled.  You may want to file a doc-bug pr.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.

This message may refer to a product containing software developed by
Christopher G. Demetriou for the NetBSD Project.