Email list hosting service & mailing list manager

Some comments Duy Nguyen (09 Sep 2020 11:37 UTC)
Re: Some comments hga@xxxxxx (09 Sep 2020 13:14 UTC)
Re: Some comments Duy Nguyen (09 Sep 2020 14:05 UTC)
Re: Some comments John Cowan (10 Sep 2020 02:04 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 03:05 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 03:21 UTC)
Re: Some comments John Cowan (10 Sep 2020 03:55 UTC)
Re: Some comments Duy Nguyen (10 Sep 2020 09:16 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 14:42 UTC)
Re: Some comments Duy Nguyen (10 Sep 2020 15:34 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 14:25 UTC)
Re: Some comments John Cowan (10 Sep 2020 15:38 UTC)
Re: Some comments Duy Nguyen (10 Sep 2020 09:28 UTC)
Re: Some comments Alex Shinn (10 Sep 2020 13:01 UTC)
(missing)
Fwd: Some comments John Cowan (10 Sep 2020 16:24 UTC)
Re: Fwd: Some comments hga@xxxxxx (10 Sep 2020 18:15 UTC)
Re: Fwd: Some comments John Cowan (10 Sep 2020 18:20 UTC)

Re: Some comments Duy Nguyen 09 Sep 2020 14:05 UTC

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