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 10 Sep 2020 09:28 UTC

On Thu, Sep 10, 2020 at 9:05 AM John Cowan <xxxxxx@ccil.org> wrote:
> This being so, a function that is thread-safe in the sense of Posix threads may be completely unsafe in the sense of user-visible threads.  Here's my new wording:
>
> <p>A Scheme implementation that supports both this SRFI and multiple
> threads of control must ensure that when a thread invokes a blocking
> procedure such as an R[4567]RS I/O operation, only that thread is
> blocked and not any other concurrently running ones.  Because
> user-visible threads may be multiplexed on a single P<small>OSIX</small>
> thread, be in a 1:1 relationship with P<small>OSIX</small> threads,
> or run on different P<small>OSIX</small> threads at different times
> in its lifecycle, there can be no guarantees that a P<small>OSIX</small>
> function which is MT-Safe (that is, thread-safe in the sense of
> P<small>OSIX</small> threads) is safe for user-visible threads.

Thanks for the mention of MT-safe.

>> I have an uneasy feeling about call-with-temporary-filename treating
>> _any_ exception as "file exists". Unrelated (and unexpected) errors
>> could also raise an exception and be misinterpteted as "file exist".
>
>
> It doesn't matter why it fails exactly: it is never dangerous to try the next name.  Admittedly, you may get an infinite loop if the prefix refers to a non-existent directory or something.  Still, I'm not too worried about it.

Imagine this. When I write the maker procedure, my fat fingers
accidentally write "cat" instead of "car". In some schemes this will
be a runtime exception. And because of this catch-all behavior,
instead of having a nice and clear exception in my face so I can fix
it, the code will just assume "file exists" and try out a couple more
names.

Eventually yes it may fail too, but that's way harder to trace back to
the "cat" typo.

> I'm reluctant to change it just before finalization.

This is likely not your intention. But when I first read this the
impression I had was "this is final, the final call is just formality,
don't any of you dare make any comments!"
--
Duy