> I noticed chroot in Chibi Scheme's system.stub, although its type of
> security is multiple cans of worms, including many developments since
> chroot was first developed.

True.

The chroot() system call can only be executed by root (at least on all
systems I've encountered). Like John, I'd caution against writing a
daemon that runs as root in Scheme. (In fact, I'd caution against
writing it in anything other than C with each line of code audited
carefully.)

A daemon written in C can always fork off Scheme subprocesses running
under other user accounts. Those can communicate with the parent process
using pipes, sockets or shared memory.

> 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).

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.

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

Staying away from signals is time well spent :)

> 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.

> There's also EBUSY, although I don't know if any of SRFI-170 can get
> that, or what should be done if you get it.

IIRC EBUSY means to "try again later" because the device or network is
unavailable, or some resource quota is currently maxed out. So fixing it
is not a simple matter of just retrying the call immediately as with
EINTR. Probably we shouldn't have special handling for EBUSY, and should
just raise an exception as for other errno values. But I could be wrong.