> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Sunday, August 11, 2019 10:28 AM

>[ Punt on chroot since it can only be called if you're root, etc. ]

>> I'd like a version of nanosleep
>> <http://pubs.opengroup.org/onlinepubs/9699919799/functions/nanosleep.html#>
>> suitably wrapped so it's only a finer grained version of sleep in e.g.
>> milliseconds, so that I can for example pause a bit on EAGAIN instead of
>> pounding the system, if retries for EAGAIN are warranted.  I've had
>> other reasons as well in times past to sleep my process for a short
>> period of time.

> This is a good idea. But should it go into a OS SRFI or a time SRFI? It
> should probably be in the same SRFI as (posix-time) and (monotonic-time).

Putting (postix-time) and (monotonic-time) in the Timespec SRFI hadn't
occurred to me, since a Timespec SRFI without them can have all its
implementation code in generic Scheme, and POSIX SRFIs necessarily
interface to the system.  On the other hand, does a Timespec SRFI
without a base source of time make sense?

> Should the sleep procedure take fractional seconds (as the sleep(1)
> command on some Unixes) or should it take seconds and nanoseconds?
> Let's keep Marc's wise comments about time representation in mind.

I was thinking fractional seconds, either milliseconds, or deciseconds
to match that use in the tty with- line discipline procedures.  Seconds
+ nanoseconds don't match my use cases for using it, especially when
you can just say for example (millisleep (* 1000 60)) if you wanted to
sleep for a minute.

>> It's been a couple of decades since I did any signal handing work,

> Staying away from signals is time well spent :)

That was my only serious experience with them, and it was quite enough.

>> but if EINTR only happens because of receiving a signal, should it
>> always be retried until it succeeds or another errno is returned,
>> ignoring the possibility of blocking in an infinite loop?

> Basically yes. There are pathological cases, such as that thing with an
> interrupted close() not being sure whether it closed the fd or not. But
> such cases are probably beyond repair need to be fixed in kernels so
> that they don't generate baffling situations for userland programs.

Still, should I e.g. insert a pause with a sleep procedure as
discussed above starting with the second retry, and then time out and
raise an error after a second?

>[ EBUSY should be raise an error, not a retry "immediately" thing. ]

But EAGAIN should be retried?  And also a) not pound on the system
using a sleep procedure and b) timeout?

- Harold