Email list hosting service & mailing list manager


Re: Some things to possibly add to SRFI-170, and errno handling questions Lassi Kortela 11 Aug 2019 16:00 UTC

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

It could make sense if other SRFIs offer interchangeable sources of
timespecs and the Scheme implementation can pick one of those SRFIs.
Need to think more about this...

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

I meant fractional seconds as in 123.456 notation, i.e. float seconds.

The trouble with picking the "right" units for each procedure is that
users will have trouble remembering which procedure takes which units.
If we use floats it doesn't matter. Another option is to use the same
precision, such as nanoseconds, for everything (obviously the syscall or
syscall wrapper will round it off to whatever units it can handle).

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

I've read lots and lots of Unix C code, and can't remember a single
program that slept before retrying after EINTR.

For EAGAIN and EBUSY, sleeping may make sense.

>> [ 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?

IIRC EAGAIN comes from trying to read a non-blocking fd that doesn't
have any data ready, or trying to write to a non-blocking fd whose write
buffer is full. Things like that. I don't know if there are any cases
where EAGAIN is used for something other than the non-blocking I/O
facility. Should double-check with someone who actually knows this stuff :)

Non-blocking fds are usually handled by select() or poll() so you only
access them if select() or poll() says you can. In those cases you
shouldn't get EAGAIN unless there's something weird going on.