On Wed, Sep 9, 2020 at 8:14 PM <xxxxxx@ancell-ent.com> wrote:
> > Should we say anything about making a port from a _directory_ fd?
> > There are some use for that in POSIX, but it's definitely not readable
> > (and absolutely not writable).
>
> In general the approach has been to mention the gotchas in using
> POSIX.  This issue doesn't sound like that, people who try to read or
> write from it will quickly find out that doesn't work, and we
> implicitly state that by having open/read/close-dir. And as you note,
> there are useful POSIX things to do with a directory, like use
> set-file-times on it.

The thing is the usefulness on POSIX is things like using the
directory fd on *at() functions or things like that. But ports don't
play that role. So it feels weird to wait until you actually read or
write to hit an error.

But on the other hand, raising an exception in this case may involve
an extra syscall (to check directory) and perhaps finding a right
errno for it. SO best to leave it undefined.

> > 3.11  Environment variables
> > ---------------------------
> >
> > The concurrency note is interesting. Can we just state that all
> > procedures in this srfi are thread safe on implementations that
> > support threads?
>
> Requires more work for the implementor, and a user could limit his
> use of the SRFI to one thread, or otherwise in the Worse is Better
> philosophy of POSIX take due care.

Is it really more work though? When I made that note I was thinking
that most of the procedures should already be thread safe because
they're light POSIX wrappers, and I didn't recognize any obvious
non-threadsafe POSIX functions (but I didn't go check). But I just
noticed that set-environment-variable! only says "should" so they're
not even required to do anything.

I don't know about you but limiting an SRFI like this to one thread
seems really limited and could have awful performance as syscalls are
issued often (now imagine all of them are serialized on one thread).

If worse is better, I don't see why we need a concurrency note for
these two procedures at all. Leave them to implementers as they need
to consider thread safety for others anyway.

A compromise could be keep the functions that are thread safe in POSIX
thread safe in this SRFI (of course only for procedures with 1-1
mapping). Leave the rest undefined in terms of concurrency.
--
Duy